[PATCH] [X86] New pass that moves immediate operands to registers.

[Serge Pavlov]

Hi Pete, Quentin,

In the specific example here for the constant 0, i’d have expected to see
> xor used to create the 0.  Any idea why that didn’t happen?  That would
> improve the code size which Quentin mentioned is a plus for this.
>

This pass can be modified to load zero in this way. Probably it is better
to improve instruction selector properly as loading zero in such way might
be useful not only for caching immediates in register.


> Also, i’ve sometimes seen neighboring 0’s being written of different
> sizes.  Would it be possible (perhaps in a future patch), to turn
>
> movq 0, 0x0(%rsi)
> movl 0, 0x8(%rsi)
>
> in to
>
> xor %rax, %rax
> movq %rax, 0x0(%rsi)
> movl %eax, 0x8(%rsi)
>
>
Yes, subregisters are taken into account. For instance instructions:

movw 0x5555, 0x0(%rsi)
movw 0x5555, 0x4(%rsi)
movb 0x55, 0x8(%rsi)

are transformed into:

movw 0x5555, %ax
movw %ax, 0x0(%rsi)
movw %ax, 0x4(%rsi)
movb %al, 0x8(%rsi)

The constant hoisting pass does this kind of things. Should we try to teach
> it to handle this kind of cases?
>
> That would be interesting. However this pass is x86 specific and can use
processor features (subregister structure, loading 64-bit value with 32-bit
move). Can theses features be used by constant hoisting?

>
>
> Moreover, this may be beneficial for code size, but I guess it is
> generally not beneficial for performances. Therefore, I believe this should
> be done for functions with the Os or Oz attributes only.
>
> Just curious, why? Moves from register must be faster than move from
memory. Both gcc and icc use moves from register when compiling with
optimization.

--Serge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141001/8f1c7ba7/attachment.html>