On Mon, Jul 24, 2017 at 3:31 PM, Marc Glisse <marc.glisse@inria.fr> wrote:
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.
Oh, no need at all, and thanks very much for all the explanation.
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.
Looks we don't really expand into def_stmt on leaf nodes, maybe
valueization can be saved in the case?