public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <richard.sandiford@arm.com>
To: Tamar Christina <tamar.christina@arm.com>
Cc: gcc-patches@gcc.gnu.org, nd@arm.com, Richard.Earnshaw@arm.com,
	Marcus.Shawcroft@arm.com, Kyrylo.Tkachov@arm.com
Subject: Re: [2/3 PATCH]AArch64 use canonical ordering for complex mul, fma and fms
Date: Fri, 17 Dec 2021 16:48:41 +0000	[thread overview]
Message-ID: <mptwnk35g9i.fsf@arm.com> (raw)
In-Reply-To: <mpt4k776vy3.fsf@arm.com> (Richard Sandiford's message of "Fri, 17 Dec 2021 16:24:36 +0000")

Richard Sandiford <richard.sandiford@arm.com> writes:
> Tamar Christina <tamar.christina@arm.com> writes:
>> Hi All,
>>
>> After the first patch in the series this updates the optabs to expect the
>> canonical sequence.
>>
>> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
>>
>> Ok for master? and backport along with the first patch?
>>
>> Thanks,
>> Tamar
>>
>> gcc/ChangeLog:
>>
>> 	PR tree-optimization/102819
>> 	PR tree-optimization/103169
>> 	* config/aarch64/aarch64-simd.md (cml<fcmac1><conj_op><mode>4,
>> 	cmul<conj_op><mode>3): Use canonical order.
>> 	* config/aarch64/aarch64-sve.md (cml<fcmac1><conj_op><mode>4,
>> 	cmul<conj_op><mode>3): Likewise.
>>
>> --- inline copy of patch -- 
>> diff --git a/gcc/config/aarch64/aarch64-simd.md b/gcc/config/aarch64/aarch64-simd.md
>> index f95a7e1d91c97c9e981d75e71f0b49c02ef748ba..875896ee71324712c8034eeff9cfb5649f9b0e73 100644
>> --- a/gcc/config/aarch64/aarch64-simd.md
>> +++ b/gcc/config/aarch64/aarch64-simd.md
>> @@ -556,17 +556,17 @@ (define_insn "aarch64_fcmlaq_lane<rot><mode>"
>>  ;; remainder.  Because of this, expand early.
>>  (define_expand "cml<fcmac1><conj_op><mode>4"
>>    [(set (match_operand:VHSDF 0 "register_operand")
>> -	(plus:VHSDF (match_operand:VHSDF 1 "register_operand")
>> -		    (unspec:VHSDF [(match_operand:VHSDF 2 "register_operand")
>> -				   (match_operand:VHSDF 3 "register_operand")]
>> -				   FCMLA_OP)))]
>> +	(plus:VHSDF (unspec:VHSDF [(match_operand:VHSDF 1 "register_operand")
>> +				   (match_operand:VHSDF 2 "register_operand")]
>> +				   FCMLA_OP)
>> +		    (match_operand:VHSDF 3 "register_operand")))]
>>    "TARGET_COMPLEX && !BYTES_BIG_ENDIAN"
>>  {
>>    rtx tmp = gen_reg_rtx (<MODE>mode);
>> -  emit_insn (gen_aarch64_fcmla<rotsplit1><mode> (tmp, operands[1],
>> -						 operands[3], operands[2]));
>> +  emit_insn (gen_aarch64_fcmla<rotsplit1><mode> (tmp, operands[3],
>> +						 operands[1], operands[2]));
>>    emit_insn (gen_aarch64_fcmla<rotsplit2><mode> (operands[0], tmp,
>> -						 operands[3], operands[2]));
>> +						 operands[1], operands[2]));
>>    DONE;
>>  })
>>  
>> @@ -583,9 +583,9 @@ (define_expand "cmul<conj_op><mode>3"
>>    rtx tmp = force_reg (<MODE>mode, CONST0_RTX (<MODE>mode));
>>    rtx res1 = gen_reg_rtx (<MODE>mode);
>>    emit_insn (gen_aarch64_fcmla<rotsplit1><mode> (res1, tmp,
>> -						 operands[2], operands[1]));
>> +						 operands[1], operands[2]));
>>    emit_insn (gen_aarch64_fcmla<rotsplit2><mode> (operands[0], res1,
>> -						 operands[2], operands[1]));
>> +						 operands[1], operands[2]));
>
> This doesn't look right.  Going from the documentation, patch 1 isn't
> changing the operand order for CMUL: the conjugated operand (if there
> is one) is still operand 2.  The FCMLA sequences use the opposite order,
> where the conjugated operand (if there is one) is operand 1.  So I think

I meant “the first multiplication operand” rather than “operand 1” here.

> the reversal here is still needed.
>
> Same for the multiplication operands in CML* above.
>
> Thanks,
> Richard

  reply	other threads:[~2021-12-17 16:48 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-17 15:42 [1/3 PATCH]middle-end vect: Simplify and extend the complex numbers validation routines Tamar Christina
2021-12-17 15:42 ` [2/3 PATCH]AArch64 use canonical ordering for complex mul, fma and fms Tamar Christina
2021-12-17 16:24   ` Richard Sandiford
2021-12-17 16:48     ` Richard Sandiford [this message]
2021-12-20 16:20       ` Tamar Christina
2022-01-11  7:10         ` Tamar Christina
2022-02-01  9:55           ` Tamar Christina
2022-02-01 11:04         ` Richard Sandiford
2021-12-17 15:43 ` [3/3 PATCH][AArch32] " Tamar Christina
2021-12-20 16:22   ` Tamar Christina
2022-01-11  7:10     ` Tamar Christina
2022-02-01  9:54       ` Tamar Christina
2022-02-01  9:56     ` Kyrylo Tkachov
2021-12-17 16:18 ` [1/3 PATCH]middle-end vect: Simplify and extend the complex numbers validation routines Richard Sandiford
2021-12-20 16:18   ` Tamar Christina
2022-01-10 10:16     ` Tamar Christina
2022-01-10 13:00 ` Richard Biener
2022-01-11  7:31   ` Tamar Christina

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=mptwnk35g9i.fsf@arm.com \
    --to=richard.sandiford@arm.com \
    --cc=Kyrylo.Tkachov@arm.com \
    --cc=Marcus.Shawcroft@arm.com \
    --cc=Richard.Earnshaw@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=nd@arm.com \
    --cc=tamar.christina@arm.com \
    /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).