around everywhere, and also give it an InsertPt member, to enable isel
to operate at an arbitrary position within a block, rather than just
appending to a block.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107791 91177308-0d34-0410-b5e6-96231b3b80d8
instance, rather than pointers to all of FunctionLoweringInfo's
members.
This eliminates an NDEBUG ABI sensitivity.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107789 91177308-0d34-0410-b5e6-96231b3b80d8
interface needs implementations to be consistent, so any code which
wants to support different semantics must use a different interface.
It's not currently worthwhile to add a new interface for this new
concept.
Document that AliasAnalysis doesn't support cross-function queries.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107776 91177308-0d34-0410-b5e6-96231b3b80d8
It is OK for an alias live range to overlap if there is a copy to or from the
physical register. CoalescerPair can work out if the copy is coalescable
independently of the alias.
This means that we can join with the actual destination interval instead of
using the getOrigDstReg() hack. It is no longer necessary to merge clobber
ranges into subregisters.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107695 91177308-0d34-0410-b5e6-96231b3b80d8
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>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107667 91177308-0d34-0410-b5e6-96231b3b80d8
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>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107580 91177308-0d34-0410-b5e6-96231b3b80d8
This code is transitional, it will soon be possible to eliminate
isExtractSubreg, isInsertSubreg, and isMoveInstr in most places.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107547 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107529 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107520 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107506 91177308-0d34-0410-b5e6-96231b3b80d8
SlotIndexes::insertMachineInstrInMaps would crash when trying to insert an
instruction imediately after an unmapped debug value.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107504 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107492 91177308-0d34-0410-b5e6-96231b3b80d8
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>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107480 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107433 91177308-0d34-0410-b5e6-96231b3b80d8
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>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107432 91177308-0d34-0410-b5e6-96231b3b80d8
