[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