On Wed, 7 Feb 2018, Jakub Jelinek wrote:
> On Wed, Feb 07, 2018 at 08:06:53AM +0100, Richard Biener wrote:
> > >Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> >
> > OK.
>
> Committed, thanks.
>
> > I wonder why we have to re-implement all this in DOM. there's enough of
> > match and simplify interfaces to make it use that?
>
> It would certainly be nicer to be able to just use match.pd here.
> I guess the intent is only do it if it folds into a constant. While we
> could use a valueize hook that would return the same SSA_NAME for both
> values, wonder if gimplify-match.c has some API to create stmts in a
> sequence only instead of replacing the stmt(s) in the IL that we could use,
> test if it is a constant and use it, otherwise throw away.
Yes it does. SCCVN for example uses it - not 100% "nice" but you
can look at vn_nary_build_or_lookup_1 for example. The interface
is using gimple_resimplify[123], passing a NULL gimple_seq (never
allow any extra stmts as simplification) and expanded ops/code.
The simplification result is in the same expanded form and you
can use gimple_simplified_result_is_gimple_val to check if it
is a singleton and then is_gimple_min_invariant if it is constant.
But maybe we can also allow SSA names as result, like from
a - b + b or so.
There's of course the gimple_fold_stmt_to_constant[_1] API that
you can also use on existing gimple stmts which will return
a is_gimple_val as well (and will valueize things in the _1 variant
with the appropriate callbacks). Not sure if everything DOM
wants to simplify is readily available in the IL though. If not,
the above interface is the correct thing to use.
Well - or simply use fold_{unary,binary} ...
Richard.
