Sink dag combine's post index load / store code that swap base ptr and index into the target hook. Only the target knows whether the swap is safe. In Thumb2 mode, the offset must be an immediate. rdar://7998649

llvm-svn: 104060

too large limit.

The function would return immediately when finding an addrmode 3/5 instruction.
It needs to keep scanning in case there is an addrmode 6 instruction which drops
the limit to 0.

A test case is very difficult to produce because it will only fail when the
scavenger is used.

rdar://problem/7894847

llvm-svn: 103995

llvm-svn: 103982

Obvious in retrospect but not fun to debug.

llvm-svn: 103969

Using NEON load / store multiple instructions will no longer create gobs of vmov of D registers!

llvm-svn: 103960

llvm-svn: 103917

llvm-svn: 103903

llvm-svn: 103901

llvm-svn: 103898

This can be extended later on to handle more "complex" constants.

llvm-svn: 103881

Temporary emit it as raw bytes until it will be added to binutils as well.

llvm-svn: 103878

llvm-svn: 103868

llvm-svn: 103855

allow target to override it in order to map register classes to illegal
but synthesizable types. e.g. v4i64, v8i64 for ARM / NEON.

llvm-svn: 103854

llvm-svn: 103851

instructions.

e.g.
%reg1026<def> = VLDMQ %reg1025<kill>, 260, pred:14, pred:%reg0
%reg1027<def> = EXTRACT_SUBREG %reg1026, 6
%reg1028<def> = EXTRACT_SUBREG %reg1026<kill>, 5
...
%reg1029<def> = REG_SEQUENCE %reg1028<kill>, 5, %reg1027<kill>, 6, %reg1028, 7, %reg1027, 8, %reg1028, 9, %reg1027, 10, %reg1030<kill>, 11, %reg1032<kill>, 12

After REG_SEQUENCE is eliminated, we are left with:

%reg1026<def> = VLDMQ %reg1025<kill>, 260, pred:14, pred:%reg0
%reg1029:6<def> = EXTRACT_SUBREG %reg1026, 6
%reg1029:5<def> = EXTRACT_SUBREG %reg1026<kill>, 5

The regular coalescer will not be able to coalesce reg1026 and reg1029 because it doesn't
know how to combine sub-register indices 5 and 6. Now 2-address pass will consult the
target whether sub-registers 5 and 6 of reg1026 can be combined to into a larger
sub-register (or combined to be reg1026 itself as is the case here). If it is possible, 
it will be able to replace references of reg1026 with reg1029 + the larger sub-register
index.

llvm-svn: 103835

llvm-svn: 103833

the variable actually tracks.

N.B., several back-ends are using "HasCalls" as being synonymous for something
that adjusts the stack. This isn't 100% correct and should be looked into.

llvm-svn: 103802

llvm-svn: 103790

llvm-svn: 103760

llvm-svn: 103749

llvm-svn: 103731

Do not use those for Thumb1 functions.

llvm-svn: 103730

llvm-svn: 103694

Bring back VLD1q and VST1q and use them for reloading / spilling Q registers. This allows folding loads and stores into VMOVQ.

llvm-svn: 103692

llvm-svn: 103684

llvm-svn: 103683

Fix some potential issues in the pseudo instruction expansion phase: copy implicit operands and memoperands. Also, expand instructions even if their defs are "dead" since they may have implicit kill operands.

llvm-svn: 103667

llvm-svn: 103642

llvm-svn: 103576

v1024 = REG_SEQUENCE ...
v1025 = EXTRACT_SUBREG v1024, 5
v1026 = EXTRACR_SUBREG v1024, 6
      = VSTxx <addr>, v1025, v1026

The REG_SEQUENCE ensures the sources that feed into the VST instruction
are getting the right register allocation so they form a large super-
register. The extract_subreg will be coalesced away all would just work:
v1024 = REG_SEQUENCE ...
      = VSTxx <addr>, v1024:5, v1024:6

The problem is if the coalescer isn't run, the extract_subreg instructions
would stick around and there is no assurance v1025 and v1026 will get the
right registers.

As a short term workaround, teach the NEON pre-allocation pass to transfer
the sub-register indices over. An alternative would be do it 2addr pass
when reg_sequence's are eliminated. But that *seems* wrong and require
updating liveness information.

Another alternative is to do this in the scheduler when the instructions are
created. But that would mean somehow the scheduler this has to be done for
correctness reason. That's yucky as well. So for now, we are leaving this
in the target specific pass.

llvm-svn: 103540

llvm-svn: 103513

to LLVM_LIBRARY_VISIBILITY and introduce LLVM_GLOBAL_VISIBILITY, which is
the opposite, for future use by dragonegg.

llvm-svn: 103495

Move EmitTargetCodeForMemcpy, EmitTargetCodeForMemset, and
EmitTargetCodeForMemmove out of TargetLowering and into
SelectionDAGInfo to exercise this.

llvm-svn: 103481

was unused. TargetMachine::getSubtarget() is used instead.

llvm-svn: 103474

llvm-svn: 103459

llvm-svn: 103453

llvm-svn: 103437

llvm-svn: 103411

whether the extract instructions are available.

rdar://7956878

llvm-svn: 103277