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 Count or Branch on Index families of instruction.
43
44--
45
46We don't use the condition code results of anything except comparisons.
47
48Implementing this may need something more finely grained than the z_cmp
49and z_ucmp that we have now.  It might (or might not) also be useful to
50have a mask of "don't care" values in conditional branches.  For example,
51integer comparisons never set CC to 3, so the bottom bit of the CC mask
52isn't particularly relevant.  JNLH and JE are equally good for testing
53equality after an integer comparison, etc.
54
55--
56
57We don't optimize string and block memory operations.
58
59--
60
61We don't take full advantage of builtins like fabsl because the calling
62conventions require f128s to be returned by invisible reference.
63
64--
65
66DAGCombiner can detect integer absolute, but there's not yet an associated
67ISD opcode.  We could add one and implement it using Load Positive.
68Negated absolutes could use Load Negative.
69
70--
71
72DAGCombiner doesn't yet fold truncations of extended loads.  Functions like:
73
74    unsigned long f (unsigned long x, unsigned short *y)
75    {
76      return (x << 32) | *y;
77    }
78
79therefore end up as:
80
81        sllg    %r2, %r2, 32
82        llgh    %r0, 0(%r3)
83        lr      %r2, %r0
84        br      %r14
85
86but truncating the load would give:
87
88        sllg    %r2, %r2, 32
89        lh      %r2, 0(%r3)
90        br      %r14
91
92--
93
94Functions like:
95
96define i64 @f1(i64 %a) {
97  %and = and i64 %a, 1
98  ret i64 %and
99}
100
101ought to be implemented as:
102
103        lhi     %r0, 1
104        ngr     %r2, %r0
105        br      %r14
106
107but two-address optimisations reverse the order of the AND and force:
108
109        lhi     %r0, 1
110        ngr     %r0, %r2
111        lgr     %r2, %r0
112        br      %r14
113
114CodeGen/SystemZ/and-04.ll has several examples of this.
115
116--
117
118Out-of-range displacements are usually handled by loading the full
119address into a register.  In many cases it would be better to create
120an anchor point instead.  E.g. for:
121
122define void @f4a(i128 *%aptr, i64 %base) {
123  %addr = add i64 %base, 524288
124  %bptr = inttoptr i64 %addr to i128 *
125  %a = load volatile i128 *%aptr
126  %b = load i128 *%bptr
127  %add = add i128 %a, %b
128  store i128 %add, i128 *%aptr
129  ret void
130}
131
132(from CodeGen/SystemZ/int-add-08.ll) we load %base+524288 and %base+524296
133into separate registers, rather than using %base+524288 as a base for both.
134
135--
136
137Dynamic stack allocations round the size to 8 bytes and then allocate
138that rounded amount.  It would be simpler to subtract the unrounded
139size from the copy of the stack pointer and then align the result.
140See CodeGen/SystemZ/alloca-01.ll for an example.
141
142--
143
144Atomic loads and stores use the default compare-and-swap based implementation.
145This is probably much too conservative in practice, and the overhead is
146especially bad for 8- and 16-bit accesses.
147