able, and modify "pro" instead of last_ok, getting rid of the
> latter.
I tried that, and it doesn't make things clearer in my opinion. Also
tried assigning "pro = pre" earlier, to make it more similar to the
previous loop; also not an improvement.
The patch also removes a su
On Wed, Jan 06, 2016 at 06:36:19AM -0600, Segher Boessenkool wrote:
> This fixes this problem. Tested on the 68909 testcase, and bootstrapped
> and regression checked on powerpc64-linux. Is this okay for trunk?
Also tested on x86_64-linux now.
Segher
> 2016-01-06 Segher Boessenkool
On 12/20/2015 05:27 PM, Segher Boessenkool wrote:
On Fri, Dec 18, 2015 at 02:19:37AM +0100, Bernd Schmidt wrote:
On 12/17/2015 10:07 PM, Segher Boessenkool wrote:
It turns out v4 wasn't quite complete anyway; so here "v5".
If a candidate PRE cannot get the prologue because a block BB is
On Fri, Dec 18, 2015 at 02:19:37AM +0100, Bernd Schmidt wrote:
> On 12/17/2015 10:07 PM, Segher Boessenkool wrote:
> >It turns out v4 wasn't quite complete anyway; so here "v5".
> >
> >If a candidate PRE cannot get the prologue because a block BB is
> >reachable from it, but PRE does not dominate
It turns out v4 wasn't quite complete anyway; so here "v5".
If a candidate PRE cannot get the prologue because a block BB is
reachable from it, but PRE does not dominate BB, we try again with the
dominators of PRE. That "try again" needs to again consider BB though,
we aren't done with it.
This
On 12/17/2015 10:07 PM, Segher Boessenkool wrote:
It turns out v4 wasn't quite complete anyway; so here "v5".
If a candidate PRE cannot get the prologue because a block BB is
reachable from it, but PRE does not dominate BB, we try again with the
dominators of PRE. That "try again" needs to
