On Thu, May 2, 2019 at 6:16 PM Segher Boessenkool <seg...@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 <l...@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 executed). Richard. > > > Segher
