switch statements in the constructors and simplifies the
implementation of the getUseType() member function. You will have to
specify defs using MachineOperand::Def instead of MOTy::Def though
(similarly for Use and UseAndDef).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11715 91177308-0d34-0410-b5e6-96231b3b80d8
implementation of a Target{RegInfo, InstrInfo, Machine, etc} now has a separate
header and a separate implementation file.
This means that instead of a massive SparcInternals.h that forces a
recompilation of the whole target whenever a minor detail is changed, you should
only recompile a few files.
Note that SparcInternals.h is still around; its contents should be minimized.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10500 91177308-0d34-0410-b5e6-96231b3b80d8
2. Handle fp-to-uint conversions directly here instead of relying on
a pre-transformation to replace them with the 2-step conversion.
3. Use size rather than explicitly checking types when deciding what
opcodes to use, wherever possible. This is less error prone (the
bug fix above was not the first time!).
4. Float-to-pointer casts shd now work though this hasn't been tested.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@7645 91177308-0d34-0410-b5e6-96231b3b80d8
causing a nasty array bound error later.
2. Fix silly typo causing logical shift of unsigned long to use
SRL instead of SRLX.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@7330 91177308-0d34-0410-b5e6-96231b3b80d8
(1) Cannot use ANDN(ot), ORN, and XORN for boolean ops, only bitwise ops.
(2) Conditional move instructions must distinguish signed and unsigned
condition codes, e.g., MOVLE vs. MOVLEU.
(3) Conditional-move-on-register was using the cond-move-on-cc opcodes,
which produces a valid-looking instruction with bogus registers!
(4) Here's a really cute one: dividing-by-2^k for negative numbers needs to
add 2^k-1 before shifting, not add 1 after shifting. Sadly, these
are the same when k=0 so our poor test case worked fine.
(5) Casting between signed and unsigned values was not correct:
completely reimplemented.
(6) Zero-extension on unsigned values was bogus: I was only doing the
SRL and not the SLLX before it. Don't know WHAT I was thinking!
(7) And the most important class of changes: Sign-extensions on signed values.
Signed values are not sign-extended after ordinary operations,
so they must be sign-extended before the following cases:
-- passing to an external or unknown function
-- returning from a function
-- using as operand 2 of DIV or REM
-- using as either operand of condition-code setting operation
(currently only SUBCC), with smaller than 32-bit operands
Also, a couple of improvements:
(1) Fold cast-to-bool into Not(bool). Need to do this for And, Or, XOR also.
(2) Convert SetCC-Const into a conditional-move-on-register (case 41)
if the constant is 0. This was only being done for branch-on-SetCC-Const
when the branch is folded with the SetCC-Const.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@7159 91177308-0d34-0410-b5e6-96231b3b80d8
integer overflow):
We need to use %icc and not %xcc for comparisons on 32-bit or smaller
integer values.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@7111 91177308-0d34-0410-b5e6-96231b3b80d8
area to avoid using up precious stack space within the 4095 offset limit
from %fp. Such objects that would themselves live at a large offset
were being put there already so this is a simple change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@7066 91177308-0d34-0410-b5e6-96231b3b80d8
(1) select: Ok to convert a pointer to a float or double.
(2) regalloc: Some MachineInstr* for caller-saving code before a call
were being inserted before and after the call!
(3) Don't insert the caller-saving instructions in the
MachineCodeForInstruction for the Call instruction.
*All* instructions generated by register allocation need to be
recorded in those maps, but it needs to be done uniformly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@7051 91177308-0d34-0410-b5e6-96231b3b80d8
* BPA and BPN do not take a %cc register as a parameter
* SLL/SRL/SRA{r,i}5 are there for a reason - they are ONLY 32-bit instructions
* Likewise, SLL/SRL/SRAX{r,i}6 are only 64-bit
* Added WRCCR{r,i} opcodes
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6655 91177308-0d34-0410-b5e6-96231b3b80d8
SparcInstrSelection.cpp:
* Fixed opcodes to return correct 'i' version since the two functions are each
only used in one place.
* Changed name of function to have an 'i' in the name to signify that they each
return an immediate form of the opcode.
* Added a warning if either of the functions is ever used in a context which
requires a register-version opcode.
SparcV9_F4.td: fixed class F4_3, added F4_4 and notes that F4_{1,2} need fixing
SparcV9.td: added the MOV(F)cc instructions
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6548 91177308-0d34-0410-b5e6-96231b3b80d8
call arguments and return values:
Now all copy operations before and after a call are generated during
selection instead of during register allocation.
The values are copied to virtual registers (or to the stack), but
in the former case these operands are marked with the correct physical
registers according to the calling convention.
Although this complicates scheduling and does not work well with
live range analysis, it simplifies the machine-dependent part of
register allocation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6465 91177308-0d34-0410-b5e6-96231b3b80d8
Here I had to make one non-trivial change: add a function to get a version of
the opcode that takes an immediate, given an opcode that takes all registers.
This is required because sometimes it is not known at construction time which
opcode is used because opcodes are passed around between functions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6375 91177308-0d34-0410-b5e6-96231b3b80d8
Fixed spilling of %fcc[0-3] which are part of %fsr.
Moved some machine-independent reg-class code to class TargetRegInfo
from SparcReg{Class,}Info.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6339 91177308-0d34-0410-b5e6-96231b3b80d8
consistent with the style of LLVM's code base (and itself! it's inconsistent in
some places.)
No functional changes were made.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6265 91177308-0d34-0410-b5e6-96231b3b80d8
