I have posted 5 patches as part of a larger series to merge
(parts) from the match-and-simplify branch. While I think
there was overall consensus that the idea behind the project
is sound there are technical questions left for how the
thing should look in the end. I've raised them in 3/n
which is the only patch of the series that contains any
patterns sofar.
To re-iterate here (as I expect most people will only look
at [0/n] patches ;)), the question is whether we are fine
with making fold-const (thus fold_{unary,binary,ternary})
not handle some cases it handles currently.
Some cases may result from the fact that the autogenerated
code from genmatch does not apply selective STRIP_NOPS/STRIP_SIGN_NOPS
to the outermost expression operands as fold does.
Some cases may result from the fact that the autogenerated
code bails out on operands with side-effects (patterns
really target GIMPLE where operands never have side-effects).
In 10 years (well, maybe earlier) we shouldn't do any
expression simplification from the frontends (and thus
GENERIC) if not explicitely required by language standards.
Thus I expect fold-const.c to "vanish" anyway.
Generally it is of course impossible to prove that adding
a pattern and removing existing fold-const.c and
gimple-fold.c/tree-ssa-forwprop.c code will not regress.
But I suppose that's expected and passing the testsuite
is fine (together with possibly amending it with testcases
for foldings that now should apply on GIMPLE).
For stage1 I'd like to merge [1/n] to [5/n] as one revision
(well, excluding 3/n) and add patterns in smaller chunks
to be able to bisect to issues that show up.
Any comments and reviews welcome (I don't think that
my maintainership covers enough to simply check this in
without approval).
Thanks,
Richard.
--
Richard Biener <rguent...@suse.de>
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer
