From: "Richard Earnshaw (lists)" <Richard.Earnshaw@arm.com>
To: Richard Henderson <richard.henderson@linaro.org>,
gcc-patches@gcc.gnu.org, marcus.shawcroft@arm.com,
segher@kernel.crashing.org, Wilco.Dijkstra@arm.com,
richard.sandiford@arm.com
Subject: Re: [PATCH v2 00/11] aarch64: Implement TImode comparisons
Date: Tue, 7 Apr 2020 10:52:10 +0100 [thread overview]
Message-ID: <01ec0411-b9b0-7233-271e-98e5dc36c6e1@arm.com> (raw)
In-Reply-To: <mptlfn8uai9.fsf@arm.com>
On 06/04/2020 12:19, Richard Sandiford wrote:
> "Richard Earnshaw (lists)" <Richard.Earnshaw@arm.com> writes:
>> On 03/04/2020 16:03, Richard Sandiford wrote:
>>> "Richard Earnshaw (lists)" <Richard.Earnshaw@arm.com> writes:
>>>> On 03/04/2020 13:27, Richard Sandiford wrote:
>>>>> "Richard Earnshaw (lists)" <Richard.Earnshaw@arm.com> writes:
>>>>>> On 02/04/2020 19:53, Richard Henderson via Gcc-patches wrote:
>>>>>>> This is attacking case 3 of PR 94174.
>>>>>>>
>>>>>>> In v2, I unify the various subtract-with-borrow and add-with-carry
>>>>>>> patterns that also output flags with unspecs. As suggested by
>>>>>>> Richard Sandiford during review of v1. It does seem cleaner.
>>>>>>>
>>>>>>
>>>>>> Really? I didn't need to use any unspecs for the Arm version of this.
>>>>>>
>>>>>> R.
>>>>>
>>>>> See https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543063.html
>>>>> (including quoted context) for how we got here.
>>>>>
>>>>> The same problem affects the existing aarch64 patterns like
>>>>> *usub<GPI:mode>3_carryinC. Although that pattern avoids unspecs,
>>>>> the compare:CC doesn't seem to be correct.
>>>>>
>>>>> Richard
>>>>>
>>>>
>>>> But I don't think you can use ANY_EXTEND in these comparisons. It
>>>> doesn't describe what the instruction does, since the instruction does
>>>> not really extend the values first.
>>>
>>> Yeah, that was the starting point in the thread above too. And using
>>> zero_extend in the existing *usub<GPI:mode>3_carryinC pattern:
>>>
>>> (define_insn "*usub<GPI:mode>3_carryinC"
>>> [(set (reg:CC CC_REGNUM)
>>> (compare:CC
>>> (zero_extend:<DWI>
>>> (match_operand:GPI 1 "register_operand" "r"))
>>> (plus:<DWI>
>>> (zero_extend:<DWI>
>>> (match_operand:GPI 2 "register_operand" "r"))
>>> (match_operand:<DWI> 3 "aarch64_borrow_operation" ""))))
>>> (set (match_operand:GPI 0 "register_operand" "=r")
>>> (minus:GPI
>>> (minus:GPI (match_dup 1) (match_dup 2))
>>> (match_operand:GPI 4 "aarch64_borrow_operation" "")))]
>>> ""
>>> "sbcs\\t%<w>0, %<w>1, %<w>2"
>>> [(set_attr "type" "adc_reg")]
>>> )
>>>
>>> looks wrong for the same reason. But the main problem IMO isn't how the
>>> inputs to the compare:CC are represented, but that we're using compare:CC
>>> at all. Using compare doesn't accurately model the effect of SBCS on NZCV
>>> for all inputs, so if we're going to use a compare here, it can't be :CC.
>>>
>>>> I would really expect this patch series to be pretty much a dual of this
>>>> series that I posted last year for Arm.
>>>>
>>>> https://gcc.gnu.org/pipermail/gcc-patches/2019-October/532180.html
>>>
>>> That series uses compares with modes like CC_V and CC_B, so I think
>>> you're saying that given the choice in the earlier thread between adding
>>> a new CC mode or using unspecs, you would have preferred a new CC mode,
>>> is that right?
>>>
>>
>> Yes. It surprised me, when doing the aarch32 version, just how often
>> the mid-end parts of the compiler were able to reason about parts of the
>> parallel insn and optimize things accordingly (eg propagating the truth
>> of the comparison). If you use an unspec that can never happen.
>
> That could be changed though. E.g. we could add something like a
> simplify_unspec target hook if this becomes a problem (either here
> or for other unspecs). A fancy implementation could even use
> match.pd-style rules in the .md file.
I really don't like that. It sounds like the top of a long slippery
slope. What about all the other cases where the RTL is comprehended by
the mid-end?
>
> The reason I'm not keen on using special modes for this case is that
> they'd describe one way in which the result can be used rather than
> describing what the instruction actually does. The instruction really
> does set all four flags to useful values. The "problem" is that they're
> not the values associated with a compare between two values, so representing
> them that way will always lose information.
>
Yes, it's true that the rtl -> machine instruction transform is not 100%
reversible. That's always been the case, but it's the price we pay for
a generic IL that describes instructions on multiple architectures.
R.
> Thanks,
> Richard
>
next prev parent reply other threads:[~2020-04-07 9:52 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-02 18:53 Richard Henderson
2020-04-02 18:53 ` [PATCH v2 01/11] aarch64: Accept 0 as first argument to compares Richard Henderson
2020-04-02 18:53 ` [PATCH v2 02/11] aarch64: Accept zeros in add<GPI>3_carryin Richard Henderson
2020-04-02 18:53 ` [PATCH v2 03/11] aarch64: Provide expander for sub<GPI>3_compare1 Richard Henderson
2020-04-02 18:53 ` [PATCH v2 04/11] aarch64: Introduce aarch64_expand_addsubti Richard Henderson
2020-04-02 18:53 ` [PATCH v2 05/11] aarch64: Use UNSPEC_SBCS for subtract-with-borrow + output flags Richard Henderson
2020-04-09 21:52 ` Segher Boessenkool
2020-04-10 3:50 ` Richard Henderson
2020-04-02 18:53 ` [PATCH v2 06/11] aarch64: Use UNSPEC_ADCS for add-with-carry " Richard Henderson
2020-04-02 18:53 ` [PATCH v2 07/11] aarch64: Remove CC_ADCmode Richard Henderson
2020-04-02 18:53 ` [PATCH v2 08/11] aarch64: Accept -1 as second argument to add<mode>3_carryin Richard Henderson
2020-04-02 18:53 ` [PATCH v2 09/11] aarch64: Adjust result of aarch64_gen_compare_reg Richard Henderson
2020-04-02 18:53 ` [PATCH v2 10/11] aarch64: Implement TImode comparisons Richard Henderson
2020-04-02 18:53 ` [PATCH v2 11/11] aarch64: Implement absti2 Richard Henderson
2020-04-02 18:55 ` [PATCH v2 00/11] aarch64: Implement TImode comparisons Richard Henderson
2020-04-03 11:34 ` Richard Earnshaw (lists)
2020-04-03 12:27 ` Richard Sandiford
2020-04-03 13:17 ` Richard Earnshaw (lists)
2020-04-03 15:03 ` Richard Sandiford
2020-04-06 9:27 ` Richard Earnshaw (lists)
2020-04-06 11:19 ` Richard Sandiford
2020-04-06 12:22 ` Richard Biener
2020-04-08 9:10 ` Richard Sandiford
2020-04-07 9:52 ` Richard Earnshaw (lists) [this message]
2020-04-07 16:32 ` Richard Sandiford
2020-04-07 17:05 ` Richard Henderson
2020-04-07 19:43 ` Segher Boessenkool
2020-04-07 20:27 ` Segher Boessenkool
2020-04-07 21:43 ` Richard Henderson
2020-04-07 23:58 ` Segher Boessenkool
2020-04-08 0:50 ` Richard Henderson
2020-04-08 20:56 ` Segher Boessenkool
2020-04-08 9:06 ` Richard Sandiford
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=01ec0411-b9b0-7233-271e-98e5dc36c6e1@arm.com \
--to=richard.earnshaw@arm.com \
--cc=Wilco.Dijkstra@arm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=marcus.shawcroft@arm.com \
--cc=richard.henderson@linaro.org \
--cc=richard.sandiford@arm.com \
--cc=segher@kernel.crashing.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).