RFC: Combine of compare & and oddity
Thu Sep 3 19:06:00 GMT 2015
On Thu, Sep 03, 2015 at 12:42:30PM -0600, Jeff Law wrote:
> Note huge parts of combine are structured around the needs of processors
> from the late 80s and early 90s. The canonical forms selected for those
> processors may not be optimal for today's processors.
Or, more precisely, for the backends for those processors. Some of the
canonicalisation rules are very inconvenient for some backends.
> The problem (of course) is changing the canonical forms can be a ton of
> work in both the backends as well as combine itself to ensure quality of
> code doesn't regress.
Yes exactly. Even more so than with other combine changes, before we
do such changes we need to evaluate 1) what this changes, on what targets;
and 2) how big the impact of that is.
Without a proposed patch, all I can say is "most targets will need changes".
> >>But the change from AND to zero_extract is already changing semantics...
> >Oh? It is not supposed to!
> Combine should never change semantics. It can change form and may
> change what happens to "don't care" bits. But it should never change
> visible semantics.
And in the reverse transform (in change_zero_ext), it is hard to tell
what those "don't care" bits are (so there are no such bits).
More information about the Gcc-patches