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
