[PATCH] D21720: Unroll for uncountable loops

[Evgeny Stupachenko via llvm-commits]

>I realize that it's possible to write such a test. My question was how frequent are such cases in real programs. Can you provide statistics from SPEC/llvm-testsuite that would justify the change?

I'll get the results for llvm test-suite. There is not much difference
on spec2000. There are gains on eembc benhmarks.

>PHIs are present in every loop, in contrast to XORs.

The patch touches only recursive XORs which also go through PHI.
PHIs for optimization after complete unroll are in countable loops. My
patch deals with uncountable (a list loop for example).

Evgeny

On Wed, Dec 14, 2016 at 6:34 PM, Michael Zolotukhin via Phabricator
<reviews at reviews.llvm.org> wrote:
> mzolotukhin added a comment.
>
>>> What is the motivation of this change? How often do we see such loops?
>>  Not each test looks like this, but there are couple where we switch states:
>>
>> state = st[s^=1];
>>  which becomes invariant with some other calculations after unroll.
>
> I realize that it's possible to write such a test. My question was how frequent are such cases in real programs. Can you provide statistics from SPEC/llvm-testsuite that would justify the change?
>
>>> If we do want to handle such cases (which I'm not convinced now), then we should do it in a general way. That is, the logic should be in instruction visitors, and we should automagically deduce that these instructions are free.
>>  The same is valid for the code above where complete unroll simplify phi. Why phi is simplified here?
>
> PHIs are present in every loop, in contrast to XORs.
>
>> The other solution is to pass, unroll factor in addition to iteration number and move simplification there.
>>  Do you think this is better?
>
> I haven't put much thought to this yet, because I'm still not convinced in the need of this change. It's possible though that if we decide to go this way, we'll need to do some prep-work first to make the code look nice. The main part of simplification code is already there (with PHI-nodes getting an extra attention due to their special and very important nature).
>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D21720
>
>
>