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

[Juergen Ributzka]

> On Oct 1, 2014, at 12:00 PM, Quentin Colombet <qcolombet at apple.com> wrote:
> 
>> 
>> On Oct 1, 2014, at 11:07 AM, Serge Pavlov <sepavloff at gmail.com <mailto:sepavloff at gmail.com>> wrote:
>> 
>> Hi Quentin,
>> 
>> 2014-10-02 0:21 GMT+07:00 Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>>:
>>>> 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? 
>> 
>> Maybe. This pass has a bunch of target hooks if I remember correctly. Juergen would know better :).

The constant hoisting pass only uses a simple target hook that returns the estimated cost of the immediate for a given instruction. This is mostly guessing, because at the LLVM IR level it is sometimes difficult to predict which instructions will be generated.

There is also the problem that the immediates are not only coalesced inside a single basic block, but also across basic blocks (which is the whole point of the constant hoisting pass) and then hoisted to a common dominator. This increases register pressure and we currently don’t track register pressure during constant hoisting. That is why we limit this to expensive immediates only.

The pass could be extended to not hoist all constants and do something similar just on the basic block level, but this overall optimization seems to be a very X86 specific code size optimization and there are even more constants generated during SelectionDAG which you wouldn’t be able to catch at LLVM IR level.

>> 
>> Ok, looking forward to advice:)
>>  
>>>> 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.
>> 
>> Yes, but those are moves from immediate, which does not require memory at all.
>> 
>> On the other hand it loads memory bus.
> 
> You mean by its encoding size or am I missing something?
> 
>>  
>> My performance concerns are:
>> - Register pressure, like Rafael mentioned.
>> - Additional scheduling dependencies.
>> 
>> Going back to your example:
>> This yields two independent chain of computation that can be scheduled independently. Moreover, you need just one register to realize this sequence.
>>   mov $0, 0x4(%esi)
>>    mov $0, 0x8(%esi)
>> 
>> The two sequences of computations have now to wait for the first mov immediate. Moreover, this sequence requires 2 registers.
>>    mov $0, %eax
>>    mov %eax, 0x4(%esi)
>>    mov %eax, 0x8(%esi)
>> 
>> 
>> Looks reasonable, thank you for explanation.
>>  
>> 
>>> Both gcc and icc use moves from register when compiling with optimization.  
>> 
>> Sure. What I am saying is that generally speaking, trading an immediate to register copy against a register to register copy does not sound like beneficial to me. 
>> 
>> Except from code size improvements, what kind of improvements are you seeing?
>>  
>> The main goal was code size. In fact the main interest is optimization of memset, the problem is described in http://llvm.org/bugs/show_bug.cgi?id=5124 <http://llvm.org/bugs/show_bug.cgi?id=5124>.  
> 
> Thanks for the context.
> This seems to confirm that, at least at first, we should do that just for Os and Oz functions (i.e., look for function attribute: OptimizeForSize and MinSize).
> 
> At this point, I’ll wait for Juergen's feedbacks on constant hoisting before doing anything.
> Based on his answer, we will see how to move forward.
> 
> Thanks again,
> -Quentin
> 
>> 
>> Also, how big are those improvements?
>> 
>> 
>> Compilation of PHP distribution with and without this pass shows size reduction about 0.3%.
>> 
>> 
>>  --Serge

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