[PATCH] D14971: X86: Emit smaller code for moving 8-bit immediates

[Hans Wennborg via llvm-commits]

hans marked an inline comment as done.

================
Comment at: lib/Target/X86/X86InstrCompiler.td:270
@@ +269,3 @@
+  let Defs = [EFLAGS], isReMaterializable = 1, isPseudo = 1 in {
+    def MOV32r1 : I<0, Pseudo, (outs GR32:$dst), (ins), "",
+                        [(set GR32:$dst, 1)]>;
----------------
DavidKreitzer wrote:
> What is the advantage of defining new pseudo-ops for mov 1 and mov -1 vs. simply using MOV32ri and expanding it post-RA where you could consider all the relevant factors such as OptForSize, OptForMinSize, the immediate value, whether the destination register requires REX, etc.?
> 
> I suppose the pseudos convey your intent to later expand to xor+inc/dec, but that hardly seems to justify the added complexity.
> 
> The new pseudos are consistent with what's being done with MOV32r0, so my question applies equally to the existing MOV32r0 code.
The reason I was doing it this way is that I was copying MOV32r0 :-)

(That one was added back in r25872, changed to be expanded by X86MCInstLower in r95433, and then to expand by expandPostRAPseudo in r198254.)

I'm still very new to the backend, so I might be getting this wrong, but one reason I can think of for having a separate instruction for MOV32r0 is to specify that it clobbers EFLAGS, whereas MOV32ri does not.

If we expanded MOV32ri in expandPostRAPseudo instead, there would be no guarantee that the instruction isn't in a place where EFLAGS is live. We could check for that situation and not use xor, but I think that would be a pessimization.

Does that make sense?


http://reviews.llvm.org/D14971