Richard Biener richard.guenther@gmail.com
Fri May 3 07:11:00 GMT 2019

On Thu, May 2, 2019 at 6:16 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
> On Thu, May 02, 2019 at 02:17:51PM +0200, Richard Biener wrote:
> > On Tue, Apr 30, 2019 at 9:53 PM Jeff Law <law@redhat.com> wrote:
> > > This is loop unswitching.  It's a standard GCC optimization.  If it's
> > > not working as well as it should, we're far better off determining why
> > > and fixing the automatic transformation rather than relying on
> > > attributes to drive the transformation.
> >
> > It's currently not implemented for switch () stmts, just for conditionals.
> > This also hurts SPEC cactusADM.  There might be a missed-optimization
> > bug about this.  A simple recursive implementation might be possible;
> > unswitch one case at a time - maybe order by profile probability.  We
> > already recurse on the unswitched bodies (in case multiple conditions
> > can be unswitched)
> Well, if for some case value we can prove the controlling expression is
> constant in the loop, we can almost always prove it is constant without
> looking at the case value?  So we can pull the whole switch statement
> outside just as easily?

There isn't any infrastructure to "easily" do that (copy the loop N times,
wrap it in a switch stmt and put the N loop copies into the switch cases).
The infrastructure we have (loop versioning) manages to copy a loop once
and wrap the two copies with a conditional.  It might be also preferable
to only unswitch the most frequently executed case to avoid code size
explosion (IIRC the cactusADM case has 4 cases, only one is actually


> Segher

More information about the Gcc mailing list