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