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][combine][RFC][2/2] PR rtl-optimization/68796: Perfer zero_extract comparison against zero rather than unsupported shorter modes


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.





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 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


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