This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Combine of compare & and oddity
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: Jeff Law <law at redhat dot com>
- Cc: Wilco Dijkstra <wdijkstr at arm dot com>, "'GCC Patches'" <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 3 Sep 2015 14:05:23 -0500
- Subject: Re: RFC: Combine of compare & and oddity
- Authentication-results: sourceware.org; auth=none
- References: <000e01d0e5a2$1e2f66b0$5a8e3410$ at com> <20150902184747 dot GA7676 at gate dot crashing dot org> <000f01d0e63d$c40686e0$4c1394a0$ at com> <20150903131809 dot GA27819 at gate dot crashing dot org> <001001d0e659$1120bb60$33623220$ at com> <20150903161825 dot GA13559 at gate dot crashing dot org> <55E89496 dot 4080202 at redhat dot com>
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