From: Richard Henderson <richard.henderson@linaro.org>
To: gcc-patches@gcc.gnu.org, richard.earnshaw@arm.com,
marcus.shawcroft@arm.com, kyrylo.tkachov@arm.com,
Wilco.Dijkstra@arm.com, richard.sandiford@arm.com,
Segher Boessenkool <segher@kernel.crashing.org>
Subject: Re: [PATCH v2 3/9] aarch64: Add <su>cmp_*_carryinC patterns
Date: Tue, 31 Mar 2020 15:44:51 -0700 [thread overview]
Message-ID: <e87f5d57-a574-387f-5a84-5bbc0b0ccdb7@linaro.org> (raw)
In-Reply-To: <mpt369o9xw4.fsf@arm.com>
On 3/31/20 11:34 AM, Richard Sandiford wrote:
>> +(define_insn "*<ANY_EXTEND:su>cmp<GPI:mode>3_carryinC"
>> + [(set (reg:CC CC_REGNUM)
>> + (compare:CC
>> + (ANY_EXTEND:<DWI>
>> + (match_operand:GPI 0 "register_operand" "r"))
>> + (plus:<DWI>
>> + (ANY_EXTEND:<DWI>
>> + (match_operand:GPI 1 "register_operand" "r"))
>> + (match_operand:<DWI> 2 "aarch64_borrow_operation" ""))))]
>> + ""
>> + "sbcs\\t<w>zr, %<w>0, %<w>1"
>> + [(set_attr "type" "adc_reg")]
>> +)
>
> I guess this feeds into your reply to Segher's comment for 7/9,
> but I think:
>
> (compare:CC X Y)
>
> is always supposed to be the NZCV flags result of X - Y, as computed in
> the mode of X and Y. If so, it seems like the type of extension should
> matter. E.g. the N flag ought to be set for:
>
> (compare:CC
> (sign_extend 0xf...)
> (plus (sign_extend 0x7...)
> (ltu ...)))
>
> but ought to be clear for:
>
> (compare:CC
> (zero_extend 0xf...)
> (plus (zero_extend 0x7...)
> (ltu ...)))
>
> If so, I guess this is a bug in the existing code...
The subject of CCmodes is a sticky one. It mostly all depends on what combine
is able to do with the patterns.
For instance, your choice of example above, even for signed, the N bit cannot
be examined by itself, because that would only be valid for a comparison
against zero, like
(compare (plus (reg) (reg))
(const_int 0))
For this particular bit of rtl, the only valid comparison is N == V, i.e. GE/LT.
If we add a new CC mode for this, what would you call it? Probably not
CC_NVmode, because to me that implies you can use either N or V, but it doesn't
imply you must examine both.
If we add more CC modes, does that mean that we have to improve SELECT_CC_MODE
to match those patterns? Or do we add new CC modes just so that combine's use
of SELECT_CC_MODE *cannot* match them?
r~
next prev parent reply other threads:[~2020-03-31 22:44 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-21 2:42 [PATCH v2 0/9] aarch64: Implement TImode comparisons Richard Henderson
2020-03-21 2:42 ` [PATCH v2 1/9] aarch64: Accept 0 as first argument to compares Richard Henderson
2020-03-31 16:55 ` Richard Sandiford
2020-03-31 17:15 ` Richard Henderson
2020-03-21 2:42 ` [PATCH v2 2/9] aarch64: Accept zeros in add<GPI>3_carryin Richard Henderson
2020-03-21 2:42 ` [PATCH v2 3/9] aarch64: Add <su>cmp_*_carryinC patterns Richard Henderson
2020-03-22 19:30 ` Segher Boessenkool
2020-03-22 20:40 ` Richard Henderson
2020-03-31 18:34 ` Richard Sandiford
2020-03-31 22:44 ` Richard Henderson [this message]
2020-04-01 12:37 ` Segher Boessenkool
2020-04-01 16:28 ` Richard Sandiford
2020-04-01 17:14 ` Richard Henderson
2020-03-21 2:42 ` [PATCH v2 4/9] aarch64: Add <su>cmp<GPI>_carryinC_m2 Richard Henderson
2020-03-21 2:42 ` [PATCH v2 5/9] aarch64: Provide expander for sub<GPI>3_compare1 Richard Henderson
2020-03-21 2:42 ` [PATCH v2 6/9] aarch64: Introduce aarch64_expand_addsubti Richard Henderson
2020-03-21 2:42 ` [PATCH v2 7/9] aarch64: Adjust result of aarch64_gen_compare_reg Richard Henderson
2020-03-22 21:55 ` Segher Boessenkool
2020-03-22 22:21 ` Richard Henderson
2020-03-21 2:42 ` [PATCH v2 8/9] aarch64: Implement TImode comparisons Richard Henderson
2020-03-21 2:42 ` [PATCH v2 9/9] aarch64: Implement absti2 Richard Henderson
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=e87f5d57-a574-387f-5a84-5bbc0b0ccdb7@linaro.org \
--to=richard.henderson@linaro.org \
--cc=Wilco.Dijkstra@arm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=kyrylo.tkachov@arm.com \
--cc=marcus.shawcroft@arm.com \
--cc=richard.earnshaw@arm.com \
--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).