spilling values used by an instruction in the delay slot of the branch
(which will eventually be moved before the branch).
2. Bug fix: Delete the delay slot instr, not the branch instr, when
moving delay slot instr. out!!!!
3. Move code to insert caller-saves moved here from SparcRegInfo:
it is now machine-independent.
llvm-svn: 7389
machine-independent.
Fix problem with using branch operand reg. as temp. reg. when
spilling values used by an instruction in the delay slot of the branch
(which will eventually be moved before the branch).
llvm-svn: 7385
info (since multiple reg types may share the same reg class).
(2) Remove machine-specific regalloc. methods that are no longer needed.
In particular, arguments and return value from a call do not need
machine-specific code for allocation.
(3) Rename TargetRegInfo::getRegType variants to avoid unintentional
overloading when an include file is omitted.
llvm-svn: 7329
(1) An int CC live range must be spilled if there are any interferences,
even if no other "neighbour" in the interf. graph has been allocated
that reg. yet. This is actually true of any class with only one reg!
(2) SparcIntCCRegClass::colorIGNode sets the color even if the LR must
be spilled so that the machine-independent spill code doesn't have to
make the machine-dependent decision of which CC name to use based on
operand type: %xcc or %icc. (These are two halves of the same
register.)
(3) LR->isMarkedForSpill() is no longer the same as LR->hasColor().
These should never have been the same, and this is necessary now for #2.
(4) All RDCCR and WRCCR instructions are directly generated with the
phony number for %ccr so that EmitAssembly/EmitBinary doesn't have to
deal with this.
llvm-svn: 7152
not just an Instruction*, at least in one unfortunate case:
the first operand to the va_arg instruction.
Modify ValueToDefVecMap to map from Value*, not Instruction*.
llvm-svn: 7052
SETTING the operand to be an immediate or have verified that one of the operands
is really a SignExtended or Unextended immediate value already, which warrants
an 'i' opcode.
llvm-svn: 6662
the loop, and in both cases. In the first case, it is a VReg that is a constant
so it may be actually converted to a constant. In the second case, it is already
a constant, but then if it doesn't change its type (e.g. to become a register
and have the value loaded from memory if it is too large to live in its
instruction field), we must change the opcode BEFORE the 'continue', otherwise
we miss the opportunity.
llvm-svn: 6602
