https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114086
--- Comment #9 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Jakub Jelinek from comment #8)
> Unfortunately doing the ((682 >> x) & 1) to x & 1 optimization in match.pd
> isn't possible, we can only use global ranges there and we need path
> specific range here.
> Can it be done in VRP pass? Though, I'm afraid I'm quite lost where it
> actually has
> the statement optimizations (rather than mere computing of ranges),
> Aldy/Andrew, any hints? I mean like what old tree-vrp.c was doing in
> simplify_stmt_using_ranges.
I don't think much has changed there... We still call into all the code in
vr-values.cc to do simplifications. I think Aldy changed it all to be
contained in class 'simplify_using_ranges'.. but those routines are all still
in vr-values.cc. tree-vrp calls into the top level simplfy() routine.
bool fold_stmt (gimple_stmt_iterator *gsi) override
{
bool ret = m_simplifier.simplify (gsi);
if (!ret)
ret = ::fold_stmt (gsi, follow_single_use_edges);
return ret;
}
If that fails, then rangers fold_stmt() is invoked. That is merely a
contextual wrapper around a call to gimple-fold::fold_stmt to see if normal
folding can find anything. Under the covers I believe that invokes match.pd
which, if it was using the current range_query, would get contextual info.
> Guess we could duplicate that in match.pd for the case which can use global
> range or
> doesn't need any range at all.
> I mean
> unsigned int
> foo (int x)
> {
> return (0xaaaaaaaaU >> x) & 1;
> }
>
> unsigned int
> bar (int x)
> {
> return (0x55555555U >> x) & 1;
> }
>
> unsigned int
> baz (int x)
> {
> if (x >= 22) __builtin_unreachable ();
> return (0x5aaaaaU >> x) & 1;
> }
> can be optimized even with global ranges (or the first one with no ranges).
> foo and baz equivalent is x & 1, while bar is (~x) & 1 or (x & 1) ^ 1, dunno
> what is more canonical.
