This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Take known zero bits into account when checking extraction.


On 04/29/2016 03:35 AM, Dominik Vogt wrote:
On Wed, Apr 27, 2016 at 10:24:21PM -0600, Jeff Law wrote:
Instead you want insn 12 to use a zero-extend to extend (reg:SI 64)
into (reg:DI 2)?

Yes, because we get the zero extend for free in this case (through
the constant in the AND or because the input value is a function
argument that is already zero extended).

Can't you achieve this in this clause:

     /* If the constant is one less than a power of two, this might be
         representable by an extraction even if no shift is present.
         If it doesn't end up being a ZERO_EXTEND, we will ignore it unless
         we are in a COMPARE.  */

You extract the constant via UINTVAL (XEXP (x, 1)), then munge it
based on nonzero_bits and pass the result to exact_log2?

That's what we tried first, but it resulted in worse code in many
places (saved about 250 instructions in the SPEC2006 testsuite but
added about 42000 elsewhere).  It was so bad that I didn't even
bother to check what's going on.  Probably this was triggered all
over the place by small constants like 1, 3, 7 and the like where
s390 has no cheap way for zero extension.  So I limited this to
constants that are actually mode masks, implicitly assuming that
there are zero extend instructions only for known modes (which is
true for s390 but may not for some other targets).  Being
conservative here shouldn't hurt; but I wonder whether there are
targets where this condition still allows too much.
You're probably right. FWIW, I do believe a variety of targets can do these kind of zero extensions. The PA for example has extru which can extract a field from a general register zero extend it, then place the result, right justified into another register.


We don't get them "for free", except as a component of a larger sequence of statements for bitfield extraction/manipulation.

I believe PPC has similar capabilities.
jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]