lib/Target/X86/README-X86-64.txt

   1 //===- README_X86_64.txt - Notes for X86-64 code gen ----------------------===//
   2
   3 Implement different PIC models? Right now we only support Mac OS X with small
   4 PIC code model.
   5
   6 //===---------------------------------------------------------------------===//
   7
   8 Make use of "Red Zone".
   9
  10 //===---------------------------------------------------------------------===//
  11
  12 For this:
  13
  14 extern void xx(void);
  15 void bar(void) {
  16   xx();
  17 }
  18
  19 gcc compiles to:
  20
  21 .globl _bar
  22 _bar:
  23         jmp     _xx
  24
  25 We need to do the tailcall optimization as well.
  26
  27 //===---------------------------------------------------------------------===//
  28
  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.
  33
  34 //===---------------------------------------------------------------------===//
  35
  36 Are we better off using branches instead of cmove to implement FP to
  37 unsigned i64?
  38
  39 _conv:
  40         ucomiss LC0(%rip), %xmm0
  41         cvttss2siq      %xmm0, %rdx
  42         jb      L3
  43         subss   LC0(%rip), %xmm0
  44         movabsq $-9223372036854775808, %rax
  45         cvttss2siq      %xmm0, %rdx
  46         xorq    %rax, %rdx
  47 L3:
  48         movq    %rdx, %rax
  49         ret
  50
  51 instead of
  52
  53 _conv:
  54         movss LCPI1_0(%rip), %xmm1
  55         cvttss2siq %xmm0, %rcx
  56         movaps %xmm0, %xmm2
  57         subss %xmm1, %xmm2
  58         cvttss2siq %xmm2, %rax
  59         movabsq $-9223372036854775808, %rdx
  60         xorq %rdx, %rax
  61         ucomiss %xmm1, %xmm0
  62         cmovb %rcx, %rax
  63         ret
  64
  65 Seems like the jb branch has high likelyhood of being taken. It would have
  66 saved a few instructions.
  67
  68 //===---------------------------------------------------------------------===//
  69
  70 Poor codegen:
  71
  72 int X[2];
  73 int b;
  74 void test(void) {
  75   memset(X, b, 2*sizeof(X[0]));
  76 }
  77
  78 llc:
  79         movq _b@GOTPCREL(%rip), %rax
  80         movzbq (%rax), %rax
  81         movq %rax, %rcx
  82         shlq $8, %rcx
  83         orq %rax, %rcx
  84         movq %rcx, %rax
  85         shlq $16, %rax
  86         orq %rcx, %rax
  87         movq %rax, %rcx
  88         shlq $32, %rcx
  89         movq _X@GOTPCREL(%rip), %rdx
  90         orq %rax, %rcx
  91         movq %rcx, (%rdx)
  92         ret
  93
  94 gcc:
  95         movq    _b@GOTPCREL(%rip), %rax
  96         movabsq $72340172838076673, %rdx
  97         movzbq  (%rax), %rax
  98         imulq   %rdx, %rax
  99         movq    _X@GOTPCREL(%rip), %rdx
 100         movq    %rax, (%rdx)
 101         ret
 102
 103 //===---------------------------------------------------------------------===//
 104
 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:
 109
 110         movzbl  %al, %edx
 111         leaq    0(,%rdx,4), %rax
 112         leaq    4+L2(%rip), %rdx
 113         leaq    239(%rsp), %rax
 114         jmp     *%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)
 123 L2:
 124
 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.
 128
 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.
 133
 134 //===---------------------------------------------------------------------===//
 135
 136 AMD64 has a complex calling convention for aggregate passing by value:
 137
 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
 140    MEMORY.
 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
 147        class.
 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
 151       class.
 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.
 156
 157 Currently llvm frontend does not handle this correctly.
 158
 159 Problem 1:
 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.
 163
 164 Problem 2:
 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.
 168
 169 Problem 3:
 170     typedef struct { int64_t i; int8_t j; int64_t d; } S;
 171     void test(S 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
 174 registers.
 175
 176 Problem 4:
 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)
 180
 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);
 184
 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
 196 memory.
 197
 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:
 200     void %test(int %d,
 201                long %undef1, long %undef2, long %undef3, long %undef4,
 202                long %undef5, long %undef6,
 203                long %s.i, byte %s.j, long %s.d);
 204
 205 //===---------------------------------------------------------------------===//
 206
 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
 210
 211 That is ok for now since we currently only support small model. So the above
 212 is selected as
 213         leaq __ZTV10polynomialIdE+16(%rip), %rax
 214
 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
 219 do the right thing.
 220
 221 //===---------------------------------------------------------------------===//
 222
 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
 226 r8b - r15b.
 227
 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).
 232
 233 //===---------------------------------------------------------------------===//
 234
 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.
 237
 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.
 242
 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.
 246
 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.
 254
 255 //===---------------------------------------------------------------------===//