Segher Boessenkool <seg...@kernel.crashing.org> writes:
> Hi!
>
> On Tue, May 26, 2020 at 08:58:13AM +0200, Richard Biener wrote:
>> On Mon, May 25, 2020 at 7:44 PM Segher Boessenkool
>> <seg...@kernel.crashing.org> wrote:
>> > Yes, cunroll does not have its own option, and that is a problem. But
>> > that is easy to fix! Either with an option, or just with params (the
>> > option wouldn't do more than set params anyway?)
>>
>> Well, given coming up with different names for essentially the same
>> transform is going to be challenging how about sth like
>>
>> -funroll-loops={early,late,static,dynamic}[insert better names here]
>
> User interface is hard :-) I think luckily we don't need to change
> anything there yet, just have an internal flag?
>
> But complete unrolling is something quite different, so it should have
> its own flag anyway (at least internally).
>
>> note there's also -fpeel-loops which may match the transform
>> done on GIMPLE better?
>
> Peeling and unrolling are the same thing, if doing complete unrolling
> (or complete peeling), followed by DCE in both cases. Peeling is a
> nicer name here I think, yeah.
>
>> I'm not sure which are the technically
>> correct terms for unrollings that elide the loop (the backedge).
>
> I don't know a better term than "complete", I don't remember ever seeing
> something else either.
How about "Var(flag_cunroll_grow_size) EnabledBy(funroll-loops ||
funroll-all-loops || fpeel-loops)" Or flag_cunroll_allow_grow_size?
And then using this flags as:
unsigned int val = tree_unroll_loops_completely (flag_cunroll_grow_size
|| optimize >= 3, true);
And we do not need to enable this flag at -O2.
Thanks for all your helpful comments again!
Jiufu
>
>> We're doing such kind of unrolling even if we cannot statically
>> decide which of a set of possible exits we take (and internally
>> call that peeling, if we can statically decide we call it complete
>> unrolling).
>
> "Peeling" is placing some copies of the loop before the loop;
> "unrolling" is placing a few copies of the loop inside the loop body.
> Does that match usage here?
>
>> The RTL side OTOH only performs classical unrolling,
>> preserving the backedge with various strategies for the
>> remaining iterations.
>
> And if you do complete unrolling that way, the backedge can be removed,
> since it can be shown never to be taken.
>
>> As said, for the regression on the 10 branch with ppc I'd add
>> [a hidden] flag that controls the RTL unroller, also set by
>> -funroll-loops and triggered by the ppc specific heuristics.
>
> But the problem is in cunroll? This is so backwards... Because some
> other transform abuses the unroller flags, adding a second level flag
> with the same meaning :-( It will work for fixing the regression,
> sure, and it is slightly less code as well.
>
>
> Segher
