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

[Rafael Auler]

On Tue, Sep 30, 2014 at 4:04 PM, Serge Pavlov <sepavloff at gmail.com> wrote:

> 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.
>
> What about the side effects in register pressure?

> --Serge
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140930/dd7e6cda/attachment.html>