[PATCH] D32563: Improve code placement algorithm in Reassociate pass.

Daniel Berlin via llvm-commits llvm-commits at lists.llvm.org
Thu Apr 27 16:44:54 PDT 2017


But if you mean you guarantee only to change decisions in the case each has
a single use (and you are not just counting the uses in the current
reassociate tree), you may actually be able to guarantee it shrinks it
globally.


On Thu, Apr 27, 2017 at 4:42 PM, Daniel Berlin <dberlin at dberlin.org> wrote:

>
>> > Maybe?
>> >
>> > Remember that this reassociate has *zero* global view of expressions.
>> > It only makes locally good choices.
>> >
>> > IE given:
>> >      bar(a + b);
>> >      bar((a + 2) + b);
>> >
>> >
>> > This reassociate will process the a + b and a + 2 + b separately,
>>
>> This patch will not change the original handling of this case because
>> both a and b has >1 uses.
>>
>>
> Sure, i was just pointing out it is only handling local tree-level stuff,
> and the way it forms trees will not necessarily guarantee that the overall
> live range of the values is reduced (precisely because the trees it forms
> do not contain all uses).
>
> IE it is guaranteed to try to shrink a live range locally, and either
> succeed or do nothing.
> That may or may not shrink a live range globally, and may increase the
> live range locally.
>
>
> IE
>        A
>         |
> A     |
> |       |
> |       |
> A      A
>
> A
> |
> |
> A
>
> ->
>
> A
> |
> |
> A   A
>       |
>       |
> A   A
> |
> |
> A
>
>
> This has shrunk the live range of A locally, but made it worse globally.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170427/2730e9df/attachment.html>


More information about the llvm-commits mailing list