Re: [PATCH][RFC] Gate loop passes group on number-of-loops > 1, add no-loops group

[Jeff Law <law at redhat dot com>]

On 06/18/14 04:42, Richard Biener wrote:
> The following aims at reducing the number of pointless passes we run
> on functions containing no loops.  Those are at least two copyprop
> and one dce pass (two dce passes when vectorization is enabled,
> three dce passes and an additional copyprop pass when any graphite
> optimization is enabled).
>
> Simply gating pass_tree_loop on number_of_loops () > 1 would disable
> basic-block vectorization on loopless functions.  Moving
> basic-block vectorization out of pass_tree_loop works to the extent
> that you'd need to move IVOPTs as well as data-ref analysis cannot
> cope with TARGET_MEM_REFs.
>
> So the following introduces a pass_tree_no_loop pass group which
> is enabled whenever the pass_tree_loop group is disabled.
> As followup this would allow to skip cleanup work we do after the loop
> pipeline just to cleanup after it.
>
> Any comments?  Does such followup sound realistic or would it be
> better to take the opportunity to move IVOPTs a bit closer to
> RTL expansion and avoid that "pass_tree_no_loop hack"?
Sounds good.  I've always believed that each pass should be bubbling 
back up some kind of status about what it did/found as well.

It was more of an RTL issue, but we had a certain commercial testsuite 
which created large loopless tests (*) that consumed vast quantities of 
wall clock time.  I always wanted the RTL loop passes to signal back to 
toplev.c that no loops were found, which would in turn be used to say 
"we really don't need cse-after-loop and friends".
It's certainly more complex these days, but I'd still like to be able to 
do such things.

Regardless, that's well outside the scope of what you're trying to 
accomplish.

* Those tests consistently found port bugs, so we really didn't want to 
disable them.

jeff