Special cases: STFSRx and STXFSRx - they operate on predefined rd=0 or rd=1, and
expect %fsr as the parameter in assembly. They are disabled (since not used)
until an encoding, both for code generation and output, is chosen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6619 91177308-0d34-0410-b5e6-96231b3b80d8
Update file comment to contain a bunch of the overview mapping-info
documentation previously buried within the file.
Remove some unnecessary include/using stmts.
Rename pass to MappingInfoCollector.
Rewrite a lot of it so it doesn't use global instance variables and so
it outputs into MappingInfo objects and then dumps those out, instead of going
straight to an assembly file.
Change name of factory to getMappingInfoCollector.
Fold prologue & epilogue writers into MappingInfo methods.
lib/Target/Sparc/FInfo.cpp:
Correct file comment to reflect above change
lib/Target/Sparc/Sparc.cpp:
Change name of factory to getMappingInfoCollector.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6617 91177308-0d34-0410-b5e6-96231b3b80d8
in Emitter.cpp, just convert the Sparc version of the constant pool into
what's already supported and inter-operate.
* Implemented a first pass at lazy function resolution in the JITResolver. That
required adding a SparcV9CodeEmitter pointer to simplify generating
bit-patterns of the instructions.
* SparcV9CodeEmitter now creates and destroys static TheJITResolver, which makes
sense because the SparcV9CodeEmitter is the only user of TheJITResolver, and
lives for the entire duration of the JIT (via PassManager which lives in VM).
* Changed all return values in the JITResolver to uint64_t because of the 64-bit
Sparc architecture.
* Added a new version of getting the value of a GlobalValue in the
SparcV9CodeEmitter, which now works for already-generated functions (JITted or
library functions).
* Removed little-used and unused functions, cleaning up the internal view of the
SparcV9CodeEmitter.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6612 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6602 91177308-0d34-0410-b5e6-96231b3b80d8
rewriting it. I also vacuumed out all the commented-out code and
inaccurate comments, etc.
(We need to put the mapping information in a data structure so that we can
pass it out to the JIT, instead of automagically converting it to .byte
directives.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6574 91177308-0d34-0410-b5e6-96231b3b80d8
they prefer the destination register to be last. Thus, two new classes were made
for them that accomodate for having this layout of operands (F3_1rd, F3_2rd).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6564 91177308-0d34-0410-b5e6-96231b3b80d8
* Labeled sections that are not currently used in the Sparc backend as not
requiring completion at this time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6562 91177308-0d34-0410-b5e6-96231b3b80d8
* Added instruction classes which start building from rs1, then rs2, and rd.
* Fixed order of operands in classes 4.1 and 4.2; added 4.6 .
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6561 91177308-0d34-0410-b5e6-96231b3b80d8
* Added new classes which start building from rs1, adding rs2, and then rd.
* Fixed order of operands in classes 3.11, 3.12, 3.16, and 3.17 .
* Fixed comments to reflect Real Life (tm).
* Removed "don't care" commented out assignments and dead classes (#if 0).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6560 91177308-0d34-0410-b5e6-96231b3b80d8
In particular these classes are the last that link the noncopyable classes
with the hash_map, vector, and list classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6552 91177308-0d34-0410-b5e6-96231b3b80d8
None of these instructions are actually used in the Sparc backend, so no changes
were required in the instruction selector.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6549 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
TmpInstruction constructors because every TmpInstruction object has
to be registered with a MachineCodeForInstruction to prevent leaks.
This simplifies the user's code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6469 91177308-0d34-0410-b5e6-96231b3b80d8
preallocated. While reg-to-reg dependences were already handled, this
change required new code for adding edges to/from call instructions.
This was part of the extensive changes to the way code generation occurs
for function call arguments and return values.
See log for CodeGen/PhyRegAlloc.cpp.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6467 91177308-0d34-0410-b5e6-96231b3b80d8
globals in some other places may not have been pulled out either;
globals in phi operands were being put just before the phi instead of
in the predecessor basic blocks.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6466 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
