https://gcc.gnu.org/bugzilla/show_bug.cgi?id=73550
--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #14)
> Seems like if we have:
> ((code_9(D) == 2))
> OR ((code_9(D) >= 3))
>
> this could be simplified down to ((code_9(D) >= 2))
>
> But I don't know if that will help this case.
The issue is the predicate we're trying to simplify against this is
is conditional on:
((_27 & 20500) AND (NOT (_26 != 0)) AND (NOT (_20 > 14)))
and that doesn't refer to code_9(D) at all. So the thing is to
handle
_20 = (unsigned int) code_9(D);
...
_27 = 1 << _20;
_26 = _27 & 480;
during normalization, turning it into a predicate based on code_9(D).
_20 > 14 might be easy (undo the unsigned range trick), but
_27 & 20500 and !(_26 != 0)? I have no idea. We prefer != to ==,
so we don't normalize !(_26 != 0) with the idea to easily identify
negated predicates. For normalizing with defs we of course want to
try normalizing _26 == 0 here. Currently normalization really only
tries to gather up || and && chains from SSA defs, not attempt to
rescue "obfuscated" base variables.
In general the predicate code relies on having the same "base" variables.
