3994be87de
The LDD/STD instructions can load/store a 64bit quantity from/to memory to/from a consecutive even/odd pair of (32-bit) registers. They are part of SparcV8, and also present in SparcV9. (Although deprecated there, as you can store 64bits in one register). As recommended on llvmdev in the thread "How to enable use of 64bit load/store for 32bit architecture" from Apr 2015, I've modeled the 64-bit load/store operations as working on a v2i32 type, rather than making i64 a legal type, but with few legal operations. The latter does not (currently) work, as there is much code in llvm which assumes that if i64 is legal, operations like "add" will actually work on it. The same assumption does not hold for v2i32 -- for vector types, it is workable to support only load/store, and expand everything else. This patch: - Adds a new register class, IntPair, for even/odd pairs of registers. - Modifies the list of reserved registers, the stack spilling code, and register copying code to support the IntPair register class. - Adds support in AsmParser. (note that in asm text, you write the name of the first register of the pair only. So the parser has to morph the single register into the equivalent paired register). - Adds the new instructions themselves (LDD/STD/LDDA/STDA). - Hooks up the instructions and registers as a vector type v2i32. Adds custom legalizer to transform i64 load/stores into v2i32 load/stores and bitcasts, so that the new instructions can actually be generated, and marks all operations other than load/store on v2i32 as needing to be expanded. - Copies the unfortunate SelectInlineAsm hack from ARMISelDAGToDAG. This hack undoes the transformation of i64 operands into two arbitrarily-allocated separate i32 registers in SelectionDAGBuilder. and instead passes them in a single IntPair. (Arbitrarily allocated registers are not useful, asm code expects to be receiving a pair, which can be passed to ldd/std.) Also adds a bunch of test cases covering all the bugs I've added along the way. Differential Revision: http://reviews.llvm.org/D8713 llvm-svn: 244484
To-do
-----
* Keep the address of the constant pool in a register instead of forming its
address all of the time.
* We can fold small constant offsets into the %hi/%lo references to constant
pool addresses as well.
* When in V9 mode, register allocate %icc[0-3].
* Add support for isel'ing UMUL_LOHI instead of marking it as Expand.
* Emit the 'Branch on Integer Register with Prediction' instructions. It's
not clear how to write a pattern for this though:
float %t1(int %a, int* %p) {
%C = seteq int %a, 0
br bool %C, label %T, label %F
T:
store int 123, int* %p
br label %F
F:
ret float undef
}
codegens to this:
t1:
save -96, %o6, %o6
1) subcc %i0, 0, %l0
1) bne .LBBt1_2 ! F
nop
.LBBt1_1: ! T
or %g0, 123, %l0
st %l0, [%i1]
.LBBt1_2: ! F
restore %g0, %g0, %g0
retl
nop
1) should be replaced with a brz in V9 mode.
* Same as above, but emit conditional move on register zero (p192) in V9
mode. Testcase:
int %t1(int %a, int %b) {
%C = seteq int %a, 0
%D = select bool %C, int %a, int %b
ret int %D
}
* Emit MULX/[SU]DIVX instructions in V9 mode instead of fiddling
with the Y register, if they are faster.
* Codegen bswap(load)/store(bswap) -> load/store ASI
* Implement frame pointer elimination, e.g. eliminate save/restore for
leaf fns.
* Fill delay slots
* Use %g0 directly to materialize 0. No instruction is required.