RFC: Combine of compare & and oddity

Jeff Law law@redhat.com
Thu Sep 3 18:42:00 GMT 2015

On 09/03/2015 10:18 AM, Segher Boessenkool wrote:
>>>> But there are more efficient ways to emit single bit and masks tests that apply
>>>> to most CPUs rather than doing something specific that works for just one target
>>>> only. For example single bit test is a simple shift into carry flag or into the
>>>> sign bit, and for mask tests, you shift out all the non-mask bits.
>>> Most of those are quite target-specific.  Some others are already done,
>>> and/or done by other passes.
>> But what combine does here is even more target-specific.
> Combine puts everything (well, most things) through
> make_compound_operation, on all targets.
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.

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.
>>> Combine converts the merged instructions to what it thinks is the
>>> canonical or cheapest form, and uses that.  It does not try multiple
>>> options (the zero_ext* -> and+shift rewriting is not changing the
>>> semantics of the pattern at all).
>> 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.


More information about the Gcc-patches mailing list