llvm-svn: 103808

llvm-svn: 103804

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

used more than once. If ISel had put a kill flag on one of them,
it's not valid to transfer the kill flag to each new instance.

llvm-svn: 103799

argument, like "int $4", to not get an Assertion error.

llvm-svn: 103791

llvm-svn: 103790

llvm-svn: 103778

control barriers, not memory ordering barriers.

llvm-svn: 103777

llvm-svn: 103776

llvm-svn: 103760

llvm-svn: 103749

llvm-svn: 103731

Do not use those for Thumb1 functions.

llvm-svn: 103730

Patch by Dimitry Andric!

llvm-svn: 103727

llvm-svn: 103702

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

after testing before committing.

llvm-svn: 103681

llvm-svn: 103677

lower them to the correct x86-64 instructions since we 
don't have a clean way to handle this in td files yet.
rdar://7947184

llvm-svn: 103668

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

part first.  rdar://7947184

llvm-svn: 103660

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: 103535

be diced into atoms, and adjust getAtom() to take this into account.
 - This fixes relocations to symbols in fixed size literal sections, for
   example.

llvm-svn: 103532

llvm-svn: 103529

llvm-svn: 103513

llvm-svn: 103507

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

llvm-svn: 103495

and the others use the regular addPassesToEmitFile hook now, and
llc no longer needs a bunch of redundant code to handle the
whole-file case.

llvm-svn: 103492

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: 103466

llvm-svn: 103459

llvm-svn: 103455

llvm-svn: 103453