1 //===- README_X86_64.txt - Notes for X86-64 code gen ----------------------===//
3 Implement different PIC models? Right now we only support Mac OS X with small
6 //===---------------------------------------------------------------------===//
8 Make use of "Red Zone".
10 //===---------------------------------------------------------------------===//
25 We need to do the tailcall optimization as well.
27 //===---------------------------------------------------------------------===//
29 AMD64 Optimization Manual 8.2 has some nice information about optimizing integer
30 multiplication by a constant. How much of it applies to Intel's X86-64
31 implementation? There are definite trade-offs to consider: latency vs. register
32 pressure vs. code size.
34 //===---------------------------------------------------------------------===//
36 Are we better off using branches instead of cmove to implement FP to
40 ucomiss LC0(%rip), %xmm0
41 cvttss2siq %xmm0, %rdx
43 subss LC0(%rip), %xmm0
44 movabsq $-9223372036854775808, %rax
45 cvttss2siq %xmm0, %rdx
54 movss LCPI1_0(%rip), %xmm1
55 cvttss2siq %xmm0, %rcx
58 cvttss2siq %xmm2, %rax
59 movabsq $-9223372036854775808, %rdx
65 Seems like the jb branch has high likelyhood of being taken. It would have
66 saved a few instructions.
68 //===---------------------------------------------------------------------===//
75 memset(X, b, 2*sizeof(X[0]));
79 movq _b@GOTPCREL(%rip), %rax
89 movq _X@GOTPCREL(%rip), %rdx
95 movq _b@GOTPCREL(%rip), %rax
96 movabsq $72340172838076673, %rdx
99 movq _X@GOTPCREL(%rip), %rdx
103 //===---------------------------------------------------------------------===//
105 Vararg function prologue can be further optimized. Currently all XMM registers
106 are stored into register save area. Most of them can be eliminated since the
107 upper bound of the number of XMM registers used are passed in %al. gcc produces
108 something like the following:
111 leaq 0(,%rdx,4), %rax
112 leaq 4+L2(%rip), %rdx
115 movaps %xmm7, -15(%rax)
116 movaps %xmm6, -31(%rax)
117 movaps %xmm5, -47(%rax)
118 movaps %xmm4, -63(%rax)
119 movaps %xmm3, -79(%rax)
120 movaps %xmm2, -95(%rax)
121 movaps %xmm1, -111(%rax)
122 movaps %xmm0, -127(%rax)
125 It jumps over the movaps that do not need to be stored. Hard to see this being
126 significant as it added 5 instruciton (including a indirect branch) to avoid
127 executing 0 to 8 stores in the function prologue.
129 Perhaps we can optimize for the common case where no XMM registers are used for
130 parameter passing. i.e. is %al == 0 jump over all stores. Or in the case of a
131 leaf function where we can determine that no XMM input parameter is need, avoid
132 emitting the stores at all.
134 //===---------------------------------------------------------------------===//
136 AMD64 has a complex calling convention for aggregate passing by value:
138 1. If the size of an object is larger than two eightbytes, or in C++, is a non-
139 POD structure or union type, or contains unaligned fields, it has class
141 2. Both eightbytes get initialized to class NO_CLASS.
142 3. Each field of an object is classified recursively so that always two fields
143 are considered. The resulting class is calculated according to the classes
144 of the fields in the eightbyte:
145 (a) If both classes are equal, this is the resulting class.
146 (b) If one of the classes is NO_CLASS, the resulting class is the other
148 (c) If one of the classes is MEMORY, the result is the MEMORY class.
149 (d) If one of the classes is INTEGER, the result is the INTEGER.
150 (e) If one of the classes is X87, X87UP, COMPLEX_X87 class, MEMORY is used as
152 (f) Otherwise class SSE is used.
153 4. Then a post merger cleanup is done:
154 (a) If one of the classes is MEMORY, the whole argument is passed in memory.
155 (b) If SSEUP is not preceeded by SSE, it is converted to SSE.
157 Currently llvm frontend does not handle this correctly.
160 typedef struct { int i; double d; } QuadWordS;
161 It is currently passed in two i64 integer registers. However, gcc compiled
162 callee expects the second element 'd' to be passed in XMM0.
165 typedef struct { int32_t i; float j; double d; } QuadWordS;
166 The size of the first two fields == i64 so they will be combined and passed in
167 a integer register RDI. The third field is still passed in XMM0.
170 typedef struct { int64_t i; int8_t j; int64_t d; } S;
172 The size of this aggregate is greater than two i64 so it should be passed in
173 memory. Currently llvm breaks this down and passed it in three integer
177 Taking problem 3 one step ahead where a function expects a aggregate value
178 in memory followed by more parameter(s) passed in register(s).
179 void test(S s, int b)
181 LLVM IR does not allow parameter passing by aggregates, therefore it must break
182 the aggregates value (in problem 3 and 4) into a number of scalar values:
183 void %test(long %s.i, byte %s.j, long %s.d);
185 However, if the backend were to lower this code literally it would pass the 3
186 values in integer registers. To force it be passed in memory, the frontend
187 should change the function signiture to:
188 void %test(long %undef1, long %undef2, long %undef3, long %undef4,
189 long %undef5, long %undef6,
190 long %s.i, byte %s.j, long %s.d);
191 And the callee would look something like this:
192 call void %test( undef, undef, undef, undef, undef, undef,
193 %tmp.s.i, %tmp.s.j, %tmp.s.d );
194 The first 6 undef parameters would exhaust the 6 integer registers used for
195 parameter passing. The following three integer values would then be forced into
198 For problem 4, the parameter 'd' would be moved to the front of the parameter
199 list so it will be passed in register:
201 long %undef1, long %undef2, long %undef3, long %undef4,
202 long %undef5, long %undef6,
203 long %s.i, byte %s.j, long %s.d);
205 //===---------------------------------------------------------------------===//
207 Right now the asm printer assumes GlobalAddress are accessed via RIP relative
208 addressing. Therefore, it is not possible to generate this:
209 movabsq $__ZTV10polynomialIdE+16, %rax
211 That is ok for now since we currently only support small model. So the above
213 leaq __ZTV10polynomialIdE+16(%rip), %rax
215 This is probably slightly slower but is much shorter than movabsq. However, if
216 we were to support medium or larger code models, we need to use the movabs
217 instruction. We should probably introduce something like AbsoluteAddress to
218 distinguish it from GlobalAddress so the asm printer and JIT code emitter can
221 //===---------------------------------------------------------------------===//
223 It's not possible to reference AH, BH, CH, and DH registers in an instruction
224 requiring REX prefix. However, divb and mulb both produce results in AH. If isel
225 emits a CopyFromReg which gets turned into a movb and that can be allocated a
228 To get around this, isel emits a CopyFromReg from AX and then right shift it
229 down by 8 and truncate it. It's not pretty but it works. We need some register
230 allocation magic to make the hack go away (e.g. putting additional constraints
231 on the result of the movb).
233 //===---------------------------------------------------------------------===//
235 The x86-64 ABI for hidden-argument struct returns requires that the
236 incoming value of %rdi be copied into %rax by the callee upon return.
238 The idea is that it saves callers from having to remember this value,
239 which would often require a callee-saved register. Callees usually
240 need to keep this value live for most of their body anyway, so it
241 doesn't add a significant burden on them.
243 We currently implement this in codegen, however this is suboptimal
244 because it means that it would be quite awkward to implement the
245 optimization for callers.
247 A better implementation would be to relax the LLVM IR rules for sret
248 arguments to allow a function with an sret argument to have a non-void
249 return type, and to have the front-end to set up the sret argument value
250 as the return value of the function. The front-end could more easily
251 emit uses of the returned struct value to be in terms of the function's
252 lowered return value, and it would free non-C frontends from a
253 complication only required by a C-based ABI.
255 //===---------------------------------------------------------------------===//