This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][combine][RFC][2/2] PR rtl-optimization/68796: Perfer zero_extract comparison against zero rather than unsupported shorter modes
- From: Kyrill Tkachov <kyrylo dot tkachov at foss dot arm dot com>
- To: Jeff Law <law at redhat dot com>, Bernd Schmidt <bschmidt at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Cc: Segher Boessenkool <segher at kernel dot crashing dot org>
- Date: Thu, 17 Dec 2015 17:04:54 +0000
- Subject: Re: [PATCH][combine][RFC][2/2] PR rtl-optimization/68796: Perfer zero_extract comparison against zero rather than unsupported shorter modes
- Authentication-results: sourceware.org; auth=none
- References: <5672D68F dot 3030408 at foss dot arm dot com> <5672DB97 dot 7090800 at redhat dot com> <5672DE74 dot 7080802 at foss dot arm dot com> <5672DEE0 dot 8000509 at redhat dot com> <5672E249 dot 6030602 at foss dot arm dot com> <5672E9EE dot 4010207 at redhat dot com>
Hi Jeff,
On 17/12/15 16:59, Jeff Law wrote:
On 12/17/2015 09:26 AM, Kyrill Tkachov wrote:
One could argue that if the target has (or advertises having) a native
QImode register comparison then it's objectively a simplification to
transform a comparison in a wider mode
to a comparison in the shorter mode.
Generally true.
The most commonly cited exception is any port that defines WORD_REGISTER_OPERATIONS. However, I would be comfortable with the idea that defining QImode comparisons on a target with WORD_REGISTER_OPERATIONS is a pretty explicit indication
that it wants to try and shorten comparisons for one reason or another.
I was investigating WORD_REGISTER_OPERATIONS as part of this. But we can't define it for aarch64.
In any case, aarch64 doesn't have QImode registers so I thought we'd try to avoid creating them.
If, however, the target doesn't have such an instruction (like aarch64
doesn't have QImode registers) then
truncating the wider mode to QImode through a subreg is not less complex
than a zero_extract, as both will
involve some form of extracting/masking the desired QImode bits. So
picking a canonical form there makes sense,
and the documentation already specifies the zero_extract form as the
canonical.
Would be nice to get a definite clarification on whether the subreg form
is indeed the canonical one.
The subreg style "extension" isn't really an extension. It is a way to say that we want to look at the object in a wider mode, but we don't actually care about the upper bits. It's generally expected that the subreg won't result in the
generation of any code.
A zero extract defines all the bits.
In this case, I'm expecting a QImode compare with zero to map down to the aarch64 TST reg, #255 instruction which
definitely zeroes out any bits outside of QImode (as it is a bitwise AND with a bitmask),
so zero_extract is the more correct expression here, no?
In theory the optimizers can use a SUBREG just like they could a REG, which should enable additional optimization. In practice I don't think that's been as true as we'd like.
jeff