Re: [PATCH GCC][1/2]Feed bound computation to folder in loop split

[Marc Glisse <marc dot glisse at inria dot fr>]

On Mon, 24 Jul 2017, Bin.Cheng wrote:

> On Mon, Jul 24, 2017 at 2:59 PM, Marc Glisse <marc.glisse@inria.fr> wrote:
> > On Mon, 24 Jul 2017, Bin.Cheng wrote:
> >
> > > But since definition of _197 isn't in current stmt sequence, call "o31
> > > = do_valueize (valueize, o31)" will return NULL.  As a result, it's
> > > not matched.
> >
> >
> > Wait, actually, how was your fold_build* version working? Why was the first
> > addition "in the current generic tree" and why isn't it "in current stmt
> > sequence"?
> Maybe I didn't express it clearly.  In compute_new_first_bound, we
> have stmt sequence "_124 = _197 + 1", and we try to simplify "_124 -
> 1" by calling gimple_build.  The definition of _197 is a PHI and isn't
> in current stmt sequence.  For fold_build* version, it builds
> expression "_197 + 1 - 1" and simplifies it.

It seems like it shouldn't be relevant whether the definition of _197 is 
in the stmt sequence or not, but indeed we seem to generate a lot of calls 
to do_valueize... I had misunderstood the issue, sorry.

Strangely, for a pattern like
(simplify (plus @0 @1) @0)
we generate no call to valueize, while for the following
(simplify (plus @0 (minus @1 @2)) @0)
we generate 3 calls to do_valueize.

I think we need Richard to say what the intent is for the valueization 
function. It is used both to stop looking at defining stmt if the return 
is NULL, and to replace/optimize one SSA_NAME with another, but currently 
it seems hard to prevent looking at the defining statement without 
preventing from looking at the SSA_NAME at all.

I guess we'll need a fix in genmatch...

--
Marc Glisse