On Mon, Jul 24, 2017 at 4:31 PM, Marc Glisse <marc.gli...@inria.fr> wrote: > On Mon, 24 Jul 2017, Bin.Cheng wrote: > >> On Mon, Jul 24, 2017 at 2:59 PM, Marc Glisse <marc.gli...@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,
Expected. We expect the "toplevel" trees to be already valueized. > 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. Yeah, this semantic overloading is an issue. For gimple_build we have nothing to "valueize" but we only use it to tell genmatch that it may not look at the SSA_NAME_DEF_STMT. > I guess we'll need a fix in genmatch... I'll have a look tomorrow. RIchard. > -- > Marc Glisse