Re: RFC: Combine of compare & and oddity

[Segher Boessenkool <segher@kernel.crashing.org>]

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).


Segher