This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Improve folding of bitwise ops on booleans
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: Andrew Pinski <pinskia at gmail dot com>
- Cc: Michael Meissner <meissner at linux dot vnet dot ibm dot com>, Richard Henderson <rth at redhat dot com>, Kai Tietz <ktietz70 at googlemail dot com>, Jeff Law <law at redhat dot com>, Richard Biener <richard dot guenther at gmail dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, David Edelsohn <dje dot gcc at gmail dot com>
- Date: Wed, 5 Jun 2013 05:34:40 +0200
- Subject: Re: [PATCH] Improve folding of bitwise ops on booleans
- References: <51A90588 dot 5080807 at redhat dot com> <CAFiYyc3yxAs0vV8qS830ubnprJSs5o4RCD+S9Pzkink_VPRzGw at mail dot gmail dot com> <51ACBEB8 dot 70005 at redhat dot com> <CAEwic4YMPzpEbjoX8moMOdVPPr7p6e6uhjZgy-=daQzgdZAy-g at mail dot gmail dot com> <51ACCBA3 dot 8040602 at redhat dot com> <20130603192226 dot GA12243 at ibm-tiger dot the-meissners dot org> <14B30893-5F30-49FA-9670-CCD466BC9569 at kernel dot crashing dot org> <CA+=Sn1=a+OVdpcKAwAzWaVYUDoF9R+tcP2v3Qwp424Co0XuefA at mail dot gmail dot com>
We cannot avoid an mfcr then, either. It would be one machine
instruction shorter though (but can be more expensive to execute,
on some CPUs).
That you get two MFCRs on 64-bit is a target bug.
Not true there. If you look at the 64bit output you will see you are
using the one cr mfcr version in 64bit while you are grabbing the full
cr in the 32bit. It depends on the processor but the one cr might be
better.
Yes, and it's still a bug. Or three:
1) GCC uses the all-fields instruction instead of the one-field
form unless you use -mmfcrf (or -mcpu=power4, etc.), although
the one-field mfcr works fine on all CPUs and is never slower
(I'm not talking about mfocrf; just the plain mfcr instruction);
2) There is a define_peephole to combine two mfcr's into one
(search rs6000.md for "3 cycle delay"); for the example code,
one of the results ends up as SI and the other as DI, and
the peephole will not trigger on that;
3) That peephole should not be enabled with -mmfcrf, and of
course it should not be a peephole at all!
Without bug 2), you'd see the same behaviour on 64-bit as on
32-bit.
Segher