Re: [PATCH][combine][RFC][2/2] PR rtl-optimization/68796: Perfer zero_extract comparison against zero rather than unsupported shorter modes

[Kyrill Tkachov <kyrylo.tkachov@foss.arm.com>]

On 17/12/15 17:27, Segher Boessenkool wrote:
> On Thu, Dec 17, 2015 at 05:12:16PM +0100, Bernd Schmidt wrote:
>> On 12/17/2015 05:10 PM, Kyrill Tkachov wrote:
>>> Well, this patch still produces the QImode comparison if the target has
>>> a QImode comparison
>>> (the have_insn_for check in the simplify_comparison hunk).
>> Ok, I didn't look that closely because I had doubts about the approach.
>> This kind of check also goes somewhat against the principles of just
>> producing canonical forms of RTL.
> The canonicalisation rules exist so that optimisers only need to match
> one form instead of several, and machine descriptions only need to
> describe one form instead of several.  For this bitmasking case it
> perversely forces you to describe the same instruction in many ways,
> for many targets.  This is what the change_zero_ext was about as well.
>
> It's not so easy to fix for the compare case.  Maybe the idea of making
> genrecog make code that recognises more forms of the same insn will work
> out.  GCC 7 in any case...

Perhaps I had underestimated how involved this issue is :)
So if I want to improve the aarch64 situation for GCC 6,
would the recommended course of action be to just define the
QI and HImode compare against zero patterns?

Note that I think the make_extraction hunk from my patch is in line
with the function comment of make_extraction that says:
"   IN_COMPARE is nonzero if we are in a COMPARE.  This means that a
     ZERO_EXTRACT should be built even for bits starting at bit 0."

whereas the condition that I'm adding "&& !in_compare" is explicitly trying
to avoid an extraction.

But anyway, if this has the potential to cause negative fallout that I
had not anticipated, it can wait for later.

Thanks,
Kyrill

>
> Segher