configuration options like CC and CXX.
Updated LLVMGCCDIR so that it refers to the valid LLVM gcc code.
Added pathnames and flags to be used by some of the tests.
Moved configuration options from Makefile.common to here since they
should all be in one place.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6404 91177308-0d34-0410-b5e6-96231b3b80d8
exit code. This, in turn, makes an empty file SparcV9CodeEmitter.inc, and only
much later, produces a link error because the key function that TableGen creates
isn't found.
Using a temporary file in the middle forces a good .INC file to be generated by
TableGen, and it will keep trying until you fix the input file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6392 91177308-0d34-0410-b5e6-96231b3b80d8
* Added some Format 4 classes, but not instructions
* Added notes on missing sections with FIXMEs
* Added RDCCR instr
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6388 91177308-0d34-0410-b5e6-96231b3b80d8
list (rd, rs1, imm), in that order (bit-wise), the actual assembly syntax is
instr rd, imm, rs1, and that is how they are constructed in the instruction
selector. This fixes the discrepancy.
Also fixed some comments along the same lines and fixed page numbers referring
to where instructions are described in the Sparc manual.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6384 91177308-0d34-0410-b5e6-96231b3b80d8
-- setCC of FP type used by a Phi: have to save in reg.
-- setNE of FP type used by a branch: cannot use result directly in branch!
-- setCC used outside the same basic block: have to save in reg. for now
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6382 91177308-0d34-0410-b5e6-96231b3b80d8
and passes the real code to a memory-outputting code emitter. This may be
removed at a later point in development.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6379 91177308-0d34-0410-b5e6-96231b3b80d8
Non-obvious change: since I have changed ST and STD to be STF and STDF to
(a) closer resemble their name (NOT assembly text) in the Sparc manual, and
(b) clearly specify that they they are floating-point opcodes,
I made the same changes in this file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6376 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
annotations on instructions to specify which format they are (i.e., do they take
2 registers and 1 immediate or just 3 registers) as that changes their binary
representation and hence, code emission.
This makes instructions more like how X86 defines them to be. Now, writers of
instruction selection must choose the correct opcode based on what instruction
type they are building, which they already know. Thus, the JIT doesn't have to
do the same work by `discovering' which operands an instruction really has.
As this involves lots of small changes to a lot of files in lib/target/Sparc,
I'll commit them individually because otherwise the diffs will be unreadable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6371 91177308-0d34-0410-b5e6-96231b3b80d8
a default value is set in the header file.
* Fixed some code layout to make it more consistent with the rest of codebase
* Added addPassesToJITCompile() with relevant passes
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6369 91177308-0d34-0410-b5e6-96231b3b80d8
* For debugging purposes:
+ output the predefined bit pattern of the instruction
* Fixed inefficiency: only load an operand from MachineInstr once
* Bug fix: did not advance bit index when seeing named bit-fields "annul", "cc"
and "predict"
* Added a catch-all for non-supported instructions at the end of switch stmt.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6368 91177308-0d34-0410-b5e6-96231b3b80d8
