[PATCH] D15494: [ELF] - implemented @indntpoff (x86) relocation and its optimization.

[Sean Silva via llvm-commits]

silvas added inline comments.

================
Comment at: ELF/Target.cpp:519-520
@@ +518,4 @@
+    // For R_386_TLS_IE relocation we perform the next transformations:
+    // MOVL foo at INDNTPOFF,%EAX is transformed to MOVL $foo,%EAX
+    // MOVL foo at INDNTPOFF,%REG is transformed to MOVL $foo,%REG
+    // ADDL foo at INDNTPOFF,%REG is transformed to ADDL $foo,%REG
----------------
ruiu wrote:
> silvas wrote:
> > ruiu wrote:
> > > Isn't the former a special case of the latter? (EAX is a REG?)
> > There is a special encoding for the EAX version, so from a linker's perspective (operations on machine code bytes) they are different. There are many x86 instructions for which eax is special (carry-over from old 8086 CISC stuff). Originally, ax = "accumulator" register and had a special "load accumulator" instruction which now is a special encoding pattern-matched by the assembler for assembly text `mov $foo,%eax`. Another example is use of cx "count" register as arg for variable bit shift.
> But still it looks odd as a comment. Maybe we should add
> 
>   // 0xA1 is RAX. RAX encoding is different from others
> 
> to 
> 
>   if (*RegSlot == 0xA1) {
> 
> ?
The comment does say "First one is special because when EAX is used the sequence is 5 bytes long, otherwise it is 6 bytes." 

Also, I think the proposed wording "0xA1 is RAX" is confusing. 0xA1 is simply the opcode byte for the instruction `MOV rAX, Ov` (see `Table A-2. One-byte Opcode Map: (00H — F7H)` in the intel manual Vol. 2).

Note that `movl $foo,%eax` actually can be encoded two ways; in one case, `*RegSlot` is just the opcode byte (see entry for 0xA1 in Table A-2), in the other, it is an opcode extension byte (see entry 0xC7 in Table A-2 and also row C7 (in group 11) column 000 in `Table A-6. Opcode Extensions for One- and Two-byte Opcodes by Group Number`). Perhaps `RegSlot` needs a different name to reflect this situation.


http://reviews.llvm.org/D15494