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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6662 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
* Removed instruction scheduling as it is too slow to run in a JIT environment
* Removed other passes because they aren't necessary and can slow JIT down
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6652 91177308-0d34-0410-b5e6-96231b3b80d8
This avoid generating a register to hold C, which in turn speeds up the
register allocator by a lot: ~9% on 164.gzip and ~17% on 256.bzip2. This
also speeds up other passes. This also speeds up execution of the program
marginally, and makes the asm much easier to read. :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6626 91177308-0d34-0410-b5e6-96231b3b80d8
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