1//===---------------------------------------------------------------------===// 2// Random notes about and ideas for the SystemZ backend. 3//===---------------------------------------------------------------------===// 4 5The initial backend is deliberately restricted to z10. We should add support 6for later architectures at some point. 7 8-- 9 10SystemZDAGToDAGISel::SelectInlineAsmMemoryOperand() is passed "m" for all 11inline asm memory constraints; it doesn't get to see the original constraint. 12This means that it must conservatively treat all inline asm constraints 13as the most restricted type, "R". 14 15-- 16 17If an inline asm ties an i32 "r" result to an i64 input, the input 18will be treated as an i32, leaving the upper bits uninitialised. 19For example: 20 21define void @f4(i32 *%dst) { 22 %val = call i32 asm "blah $0", "=r,0" (i64 103) 23 store i32 %val, i32 *%dst 24 ret void 25} 26 27from CodeGen/SystemZ/asm-09.ll will use LHI rather than LGHI. 28to load 103. This seems to be a general target-independent problem. 29 30-- 31 32The tuning of the choice between LOAD ADDRESS (LA) and addition in 33SystemZISelDAGToDAG.cpp is suspect. It should be tweaked based on 34performance measurements. 35 36-- 37 38There is no scheduling support. 39 40-- 41 42We don't use the BRANCH ON INDEX instructions. 43 44-- 45 46We might want to use BRANCH ON CONDITION for conditional indirect calls 47and conditional returns. 48 49-- 50 51We don't use the TEST DATA CLASS instructions. 52 53-- 54 55We could use the generic floating-point forms of LOAD COMPLEMENT, 56LOAD NEGATIVE and LOAD POSITIVE in cases where we don't need the 57condition codes. For example, we could use LCDFR instead of LCDBR. 58 59-- 60 61We only use MVC, XC and CLC for constant-length block operations. 62We could extend them to variable-length operations too, 63using EXECUTE RELATIVE LONG. 64 65MVCIN, MVCLE and CLCLE may be worthwhile too. 66 67-- 68 69We don't use CUSE or the TRANSLATE family of instructions for string 70operations. The TRANSLATE ones are probably more difficult to exploit. 71 72-- 73 74We don't take full advantage of builtins like fabsl because the calling 75conventions require f128s to be returned by invisible reference. 76 77-- 78 79ADD LOGICAL WITH SIGNED IMMEDIATE could be useful when we need to 80produce a carry. SUBTRACT LOGICAL IMMEDIATE could be useful when we 81need to produce a borrow. (Note that there are no memory forms of 82ADD LOGICAL WITH CARRY and SUBTRACT LOGICAL WITH BORROW, so the high 83part of 128-bit memory operations would probably need to be done 84via a register.) 85 86-- 87 88We don't use the halfword forms of LOAD REVERSED and STORE REVERSED 89(LRVH and STRVH). 90 91-- 92 93We don't use ICM or STCM. 94 95-- 96 97DAGCombiner doesn't yet fold truncations of extended loads. Functions like: 98 99 unsigned long f (unsigned long x, unsigned short *y) 100 { 101 return (x << 32) | *y; 102 } 103 104therefore end up as: 105 106 sllg %r2, %r2, 32 107 llgh %r0, 0(%r3) 108 lr %r2, %r0 109 br %r14 110 111but truncating the load would give: 112 113 sllg %r2, %r2, 32 114 lh %r2, 0(%r3) 115 br %r14 116 117-- 118 119Functions like: 120 121define i64 @f1(i64 %a) { 122 %and = and i64 %a, 1 123 ret i64 %and 124} 125 126ought to be implemented as: 127 128 lhi %r0, 1 129 ngr %r2, %r0 130 br %r14 131 132but two-address optimisations reverse the order of the AND and force: 133 134 lhi %r0, 1 135 ngr %r0, %r2 136 lgr %r2, %r0 137 br %r14 138 139CodeGen/SystemZ/and-04.ll has several examples of this. 140 141-- 142 143Out-of-range displacements are usually handled by loading the full 144address into a register. In many cases it would be better to create 145an anchor point instead. E.g. for: 146 147define void @f4a(i128 *%aptr, i64 %base) { 148 %addr = add i64 %base, 524288 149 %bptr = inttoptr i64 %addr to i128 * 150 %a = load volatile i128 *%aptr 151 %b = load i128 *%bptr 152 %add = add i128 %a, %b 153 store i128 %add, i128 *%aptr 154 ret void 155} 156 157(from CodeGen/SystemZ/int-add-08.ll) we load %base+524288 and %base+524296 158into separate registers, rather than using %base+524288 as a base for both. 159 160-- 161 162Dynamic stack allocations round the size to 8 bytes and then allocate 163that rounded amount. It would be simpler to subtract the unrounded 164size from the copy of the stack pointer and then align the result. 165See CodeGen/SystemZ/alloca-01.ll for an example. 166 167-- 168 169If needed, we can support 16-byte atomics using LPQ, STPQ and CSDG. 170 171-- 172 173We might want to model all access registers and use them to spill 17432-bit values. 175