does not.

llvm-svn: 107546

AliasAnalyses have the choice to respect noalias.

llvm-svn: 107544

llvm-svn: 107540

llvm-svn: 107538

llvm-svn: 107537

The COPY instruction is intended to replace the target specific copy
instructions for virtual registers as well as the EXTRACT_SUBREG and
INSERT_SUBREG instructions in MachineFunctions. It won't we used in a selection
DAG.

COPY is lowered to native register copies by LowerSubregs.

llvm-svn: 107529

- Fix VEX prefix to be emitted with 3 bytes whenever VEX_5M
represents a REX equivalent two byte leading opcode

llvm-svn: 107523

list of predefined instructions appear. Add some consistency checks.

Ideally, TargetOpcodes.h should be produced by TableGen from Target.td, but it
is hardly worth the effort.

llvm-svn: 107520

new basic blocks, and if used as a function argument, that can cause call frame
setup / destroy pairs to be split across a basic block boundary. That prevents
us from doing a simple assertion to check that the pairs match and alloc/
dealloc the same amount of space. Modify the assertion to only check the
amount allocated when there are matching pairs in the same basic block.

rdar://8022442

llvm-svn: 107517

llvm-svn: 107516

llvm-svn: 107513

- X86 unfolding should check if the instructions being unfolded has memoperands.
  If there is no memoperands, then it must assume conservative alignment. If this
  would introduce an expensive sse unaligned load / store, then unfoldMemoryOperand
  etc. should not unfold the instruction.

llvm-svn: 107509

llvm-svn: 107507

PrologEpilog code, and use it to determine whether
the asm forces stack alignment or not.  gcc consistently
does not do this for GCC-style asms; Apple gcc inconsistently
sometimes does it for asm blocks.  There is no
convenient place to put a bit in either the SDNode or
the MachineInstr form, so I've added an extra operand
to each; unlovely, but it does allow for expansion for
more bits, should we need it.  PR 5125.  Some
existing testcases are affected.
The operand lists of the SDNode and MachineInstr forms
are indexed with awesome mnemonics, like "2"; I may
fix this someday, but not now.  I'm not making it any
worse.  If anyone is inspired I think you can find all
the right places from this patch.

llvm-svn: 107506

llvm-svn: 107505

SlotIndexes::insertMachineInstrInMaps would crash when trying to insert an
instruction imediately after an unmapped debug value.

llvm-svn: 107504

llvm-svn: 107503

llvm-svn: 107500

llvm-svn: 107498

have any effect, and second, deleting stores can potentially invalidate
an AliasAnalysis, and there's currently no notification for this.

llvm-svn: 107496

the noalias argument on function attributes be usable to model the
C99 restrict keyword on arguments, and to allow AliasAnalysis to
consider a noalias-attributed argument to be an "identified object".

To support this, refactor a new "based on" concept out of the current
pointer aliasing "associated" concept. This "based on" concept is very
similar to (though it is not identical with) the "based on" concept
in C99.

Also, reword the definition of NoAlias to more closely describe the
concept that the optimizer uses.

llvm-svn: 107495

This allows us to recognize the common case where all uses could be
rematerialized, and no stack slot allocation is necessary.

If some values could be fully rematerialized, remove them from the live range
before allocating a stack slot for the rest.

llvm-svn: 107492

llvm-svn: 107490

llvm-svn: 107489

that it checks the immediate values, not just the instructions opcodes.
Radar 8110263.

llvm-svn: 107487

llvm-svn: 107482

llvm-svn: 107481

second round of low-level interface squeeze-out:
making all of CallInst's low-level operand accessors
private

If you get compile errors I strongly urge you to
update your code.


I tried to write the necessary clues into the
header where the compiler may point to, but no
guarantees. It works for my GCC.

You have several options to update your code:

- you can use the v2.8 ArgOperand accessors
- you can go via a temporary CallSite
- you can upcast to, say, User and call its
  low-level accessors if your code is definitely
  operand-order agnostic.

If you run into serious problems, please
comment in below thread (and back out this
revision only if absolutely necessary):

<http://groups.google.com/group/llvm-dev/browse_thread/thread/64650cf343b28271>

llvm-svn: 107480

llvm-svn: 107458

llvm-svn: 107454

llvm-svn: 107451

llvm-svn: 107448

llvm-svn: 107446

will still be stripped by the linker when it generates the final image.

llvm-svn: 107440

llvm-svn: 107438

getFunctionAlignment and the corresponding use of that value in the ARM
asm printer, but now we're using the standard asm printer.  The result of
this was that function alignments were dropped completely for Thumb functions.
Radar 8143571.

llvm-svn: 107435

Objective-C metadata types which should be marked as "weak", but which the
linker will remove upon final linkage. However, this linkage isn't specific to
Objective-C.

For example, the "objc_msgSend_fixup_alloc" symbol is defined like this:

      .globl l_objc_msgSend_fixup_alloc
      .weak_definition l_objc_msgSend_fixup_alloc
      .section __DATA, __objc_msgrefs, coalesced
      .align 3
l_objc_msgSend_fixup_alloc:
       .quad   _objc_msgSend_fixup
       .quad   L_OBJC_METH_VAR_NAME_1

This is different from the "linker_private" linkage type, because it can't have
the metadata defined with ".weak_definition".

Currently only supported on Darwin platforms.

llvm-svn: 107433

to update their code to high-level interfaces

If you get compile errors in your project
please update your code according to the
comments.

This is a re-commit of r107396 which causes
compile errors for the indicated usage patterns
instead of link errors (which are less easy to
fix because of missing source location).

If you get compile errors please perform
following functionally equivalent transformations:
  - getOperand(0)  --->  getCalledValue()
  - setOperand(0, V)  --->  setCalledFunction(V)

This will make your code more future-proof
and avoid potentially hard-to-debug bugs.

please refer to this thread on llvm-dev:

<http://groups.google.com/group/llvm-dev/browse_thread/thread/64650cf343b28271>

llvm-svn: 107432

This is a regression caused by r106792 and caught by gdb testsuite.

llvm-svn: 107430

llvm-svn: 107428