Re: [PR tree-optimization/71691] Fix unswitching in presence of maybe-undef SSA_NAMEs (take 2)

[Aldy Hernandez <aldyh at redhat dot com>]

On 01/26/2017 07:29 AM, Richard Biener wrote:
> On Thu, Jan 26, 2017 at 1:04 PM, Aldy Hernandez <aldyh@redhat.com> wrote:
> > On 01/24/2017 07:23 AM, Richard Biener wrote:

> Your initial on-demand approach is fine to catch some of the cases but it
> will not handle those for which we'd need post-dominance.
>
> I guess we can incrementally add that.

No complaints from me.

This is my initial on-demand approach, with a few fixes you've commented 
on throughout.

As you can see, there is still an #if 0 wrt to using your suggested 
conservative handling of memory loads, which I'm not entirely convinced 
of, as it pessimizes gcc.dg/loop-unswitch-1.c.  If you feel strongly 
about it, I can enable the code again.

Also, I enhanced gcc.dg/loop-unswitch-1.c to verify that we're actually 
unswitching something.  It seems kinda silly that we have various 
unswitch tests, but we don't actually check whether we have unswitched 
anything.  This test was the only one in the *unswitch*.c set that I saw 
was actually being unswitched.  Of course, if you don't agree with my 
#if 0 above, I will remove this change to the test.

Finally, are we even guaranteed to unswitch in loop-unswitch-1.c across 
architectures?  If not, again, I can remove the one-liner.

How does this look for trunk?

Aldy

Attachment: curr
Description: Text document