[llvm] r200022 - Add Constant Hoisting Pass

Juergen Ributzka juergen at apple.com
Mon Jan 27 13:52:57 PST 2014


Hi Quentin,

I read your email to quickly. I will extend the unit test to also check the opt result.

-Juergen

On Jan 27, 2014, at 1:50 PM, Juergen Ributzka <juergen at apple.com> wrote:

> Hi Quentin,
> 
> the constant coalescing code isn’t that clever, so you won’t have a chain of adds to get the final constant. There is always at most one add between the materialization of the base constant and its use.
> For the test case I found it to be much easier to just count the number of constant materializations.
> 
> Cheers,
> Juergen
> 
> On Jan 24, 2014, at 11:06 AM, Quentin Colombet <qcolombet at apple.com> wrote:
> 
>> Hi Juergen,
>> 
>> Sorry for the late comments on this.
>> 1. I have one comment on the added test case, see inline comments.
>> 2. When you create a displacement from one constant to another, you are creating data dependencies. I know that you did not measure any performance impact for this pass, but is the scheduler able to break these dependency it is increase the critical path?
>> What I have in mind in something like this:
>> 
>> Before:
>> op1 BigCst
>> op2 BigCst+MaxDisplacement
>> op3 BigCst+2*MaxDisplacement
>> =>
>> 
>> After:
>> regCst = bitcast BigCst
>> op1 regCst
>> regCst2 = add regCst, MaxDisplacement
>> op2 regCst2
>> regCst3 = add regCst2, MaxDisplacement
>> op3 regCst3
>> 
>> Before has 3 independent computations.
>> After has one big chain of computation.
>> 
>> That said, I believe that wouldn’t happen often, just curious :).
>> 
>> Thanks,
>> -Quentin
> 

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


More information about the llvm-commits mailing list