EXTRACT_SUBREG no longer appears as a machine instruction. Use COPY instead.
Add isCopy() checks in many places using isMoveInstr() and isExtractSubreg().
The isMoveInstr hook will be removed later.
llvm-svn: 107879
This target hook is intended to replace copyRegToReg entirely, but for now it
calls copyRegToReg.
Any remaining calls to copyRegToReg wil be replaced by COPY instructions.
llvm-svn: 107854
(if there are any) and use the one which remains available for the longest
rather than just using the first one. This should help enable better re-use
of the loaded frame index values. rdar://7318760
llvm-svn: 107847
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.
llvm-svn: 107791
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.
llvm-svn: 107776
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.
llvm-svn: 107695
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: 107667
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: 107580
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
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
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
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
