Re: [PATCH][AArch64] Use preferred aliases for CSNEG, CSINC, CSINV

[Kyrill Tkachov]

Hi Andrew,

On 12/09/15 02:15, Andrew Pinski wrote:

On Tue, Sep 1, 2015 at 6:08 PM, Kyrill Tkachov  wrote:

Hi all,

The ARMv8-A reference manual says:
"CNEG , , 
is equivalent to
CSNEG , , , invert()
and is the preferred disassembly when Rn == Rm && cond != '111x'."

That is, when the two input registers are the same we can use the shorter
CNEG mnemonic
with the inverse condition instead of the longer CSNEG instruction.
Similarly for the
CSINV and CSINC instructions, they have shorter CINV and CINC forms.
This patch adjusts the output templates to emit the preferred shorter
sequences when possible.

The new mnemonics are just aliases, they map down to the same instruction in
the end, so there
are no performance or behaviour implications. But it does make the assembly
a bit more readable
IMO, since:
"cnegw27, w9, le"
can be simply read as "if the condition is less or equal negate w9" instead
of the previous:
"csnegw27, w9, w9, gt" where you have to remember which of the input
registers is negated.


Bootstrapped and tested on aarch64-linux-gnu.
Ok for trunk?

I really think this kind of special casing is not correct and does not
belong in the compiler.  The main reason it complicates the back-end
more than the benefit of easier of reading the assembly code.


.
The complication is an extra if-else statement with
explicit strings on each arm i.e. there's no snprintf trickery.
I tend to read a lot of the generated assembly when performing assembly
comparisons while working on performance patches and I find that having
the cneg from with two register operands and the negate condition is quicker
to parse than the full csneg form where I need to remember that extra bit
of info that the condition there must be inverted to get the negation condition.

If you feel very strongly against this I can withdraw this patch, but I'd 
rather have it in.
FWIW, clang also emits the CNEG when it can AFAICS, though I admit that's not 
necessarily a strong
argument for this change.

Kyrill



Thanks,
Andrew Pinski


Thanks,
Kyrill

2015-09-01  Kyrylo Tkachov  

 * config/aarch64/aarch64.md (csinc3_insn): Use CINC
 mnemonic when possible.
 (*csinv3_insn): Use CINV mnemonic when possible.
 (csneg3_insn): USE CNEG mnemonic when possible.

2015-09-01  Kyrylo Tkachov  

 * gcc.target/aarch64/abs_1.c: Update scan-assembler checks
 to allow cneg.
 * gcc.target/aarch64/cond_op_imm_1.c: Likewise.  Likewise for cinv.
 * gcc.target/aarch64/mod_2.c: Likewise.

Re: [PATCH][AArch64] Use preferred aliases for CSNEG, CSINC, CSINV

[Kyrill Tkachov]

On 11/09/15 16:31, James Greenhalgh wrote:

On Tue, Sep 01, 2015 at 11:08:10AM +0100, Kyrill Tkachov wrote:

Hi all,

The ARMv8-A reference manual says:
"CNEG , , 
is equivalent to
CSNEG , , , invert()
and is the preferred disassembly when Rn == Rm && cond != '111x'."

That is, when the two input registers are the same we can use the shorter CNEG 
mnemonic
with the inverse condition instead of the longer CSNEG instruction. Similarly 
for the
CSINV and CSINC instructions, they have shorter CINV and CINC forms.
This patch adjusts the output templates to emit the preferred shorter sequences 
when possible.

The new mnemonics are just aliases, they map down to the same instruction in 
the end, so there
are no performance or behaviour implications. But it does make the assembly a 
bit more readable
IMO, since:
"cnegw27, w9, le"
can be simply read as "if the condition is less or equal negate w9" instead of 
the previous:
"csnegw27, w9, w9, gt" where you have to remember which of the input 
registers is negated.


Bootstrapped and tested on aarch64-linux-gnu.
Ok for trunk?

diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 77bc7cd..2e4b26c 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -3090,7 +3090,12 @@ (define_insn "csinc3_insn"
(const_int 1))
  (match_operand:GPI 3 "aarch64_reg_or_zero" "rZ")))]
""
-  "csinc\\t%0, %3, %2, %M1"
+  {
+if (rtx_equal_p (operands[2], operands[3]))
+  return "cinc\\t%0, %2, %m1";
+else
+  return "csinc\\t%0, %3, %2, %M1";
+  }
[(set_attr "type" "csel")]
  )

I guess you do it this way rather than just adding a new alternative in
the pattern to avoid any chance of constraining the register allocator, but
would this not be more natural to read as an {r, r, r, 2} alternative, or
similar?


I had not considered this approach and I'm a bit sceptical on how feasible it 
is.
If we put the {r,r,r,2} as a second alternative then it will be a purely more 
restrictive
version of the first alternative and so will never match.
If, however, we put it as the first alternative we'll be expressing some 
preference for
allocating the same register for operands 2 and 3, which is not something we 
want to do.



If you've given that some thought and decided it doesn't work for you,
then this is OK for trunk.

Given the above
I'll commit this version next week if there are no objections.

Thanks,
Kyrill



Thanks,
James

Re: [PATCH][AArch64] Use preferred aliases for CSNEG, CSINC, CSINV

[Andrew Pinski]

On Tue, Sep 1, 2015 at 6:08 PM, Kyrill Tkachov  wrote:
> Hi all,
>
> The ARMv8-A reference manual says:
> "CNEG , , 
> is equivalent to
> CSNEG , , , invert()
> and is the preferred disassembly when Rn == Rm && cond != '111x'."
>
> That is, when the two input registers are the same we can use the shorter
> CNEG mnemonic
> with the inverse condition instead of the longer CSNEG instruction.
> Similarly for the
> CSINV and CSINC instructions, they have shorter CINV and CINC forms.
> This patch adjusts the output templates to emit the preferred shorter
> sequences when possible.
>
> The new mnemonics are just aliases, they map down to the same instruction in
> the end, so there
> are no performance or behaviour implications. But it does make the assembly
> a bit more readable
> IMO, since:
> "cnegw27, w9, le"
> can be simply read as "if the condition is less or equal negate w9" instead
> of the previous:
> "csnegw27, w9, w9, gt" where you have to remember which of the input
> registers is negated.
>
>
> Bootstrapped and tested on aarch64-linux-gnu.
> Ok for trunk?

I really think this kind of special casing is not correct and does not
belong in the compiler.  The main reason it complicates the back-end
more than the benefit of easier of reading the assembly code.

Thanks,
Andrew Pinski

>
> Thanks,
> Kyrill
>
> 2015-09-01  Kyrylo Tkachov  
>
> * config/aarch64/aarch64.md (csinc3_insn): Use CINC
> mnemonic when possible.
> (*csinv3_insn): Use CINV mnemonic when possible.
> (csneg3_insn): USE CNEG mnemonic when possible.
>
> 2015-09-01  Kyrylo Tkachov  
>
> * gcc.target/aarch64/abs_1.c: Update scan-assembler checks
> to allow cneg.
> * gcc.target/aarch64/cond_op_imm_1.c: Likewise.  Likewise for cinv.
> * gcc.target/aarch64/mod_2.c: Likewise.

Re: [PATCH][AArch64] Use preferred aliases for CSNEG, CSINC, CSINV

[Kyrill Tkachov]

Ping.
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00020.html

Thanks,
Kyrill

On 01/09/15 11:08, Kyrill Tkachov wrote:

Hi all,

The ARMv8-A reference manual says:
"CNEG , , 
is equivalent to
CSNEG , , , invert()
and is the preferred disassembly when Rn == Rm && cond != '111x'."

That is, when the two input registers are the same we can use the shorter CNEG 
mnemonic
with the inverse condition instead of the longer CSNEG instruction. Similarly 
for the
CSINV and CSINC instructions, they have shorter CINV and CINC forms.
This patch adjusts the output templates to emit the preferred shorter sequences 
when possible.

The new mnemonics are just aliases, they map down to the same instruction in 
the end, so there
are no performance or behaviour implications. But it does make the assembly a 
bit more readable
IMO, since:
"cnegw27, w9, le"
can be simply read as "if the condition is less or equal negate w9" instead of 
the previous:
"csnegw27, w9, w9, gt" where you have to remember which of the input 
registers is negated.


Bootstrapped and tested on aarch64-linux-gnu.
Ok for trunk?

Thanks,
Kyrill

2015-09-01  Kyrylo Tkachov  

  * config/aarch64/aarch64.md (csinc3_insn): Use CINC
  mnemonic when possible.
  (*csinv3_insn): Use CINV mnemonic when possible.
  (csneg3_insn): USE CNEG mnemonic when possible.

2015-09-01  Kyrylo Tkachov  

  * gcc.target/aarch64/abs_1.c: Update scan-assembler checks
  to allow cneg.
  * gcc.target/aarch64/cond_op_imm_1.c: Likewise.  Likewise for cinv.
  * gcc.target/aarch64/mod_2.c: Likewise.

Re: [PATCH][AArch64] Use preferred aliases for CSNEG, CSINC, CSINV

[James Greenhalgh]

On Tue, Sep 01, 2015 at 11:08:10AM +0100, Kyrill Tkachov wrote:
> Hi all,
> 
> The ARMv8-A reference manual says:
> "CNEG , , 
> is equivalent to
> CSNEG , , , invert()
> and is the preferred disassembly when Rn == Rm && cond != '111x'."
> 
> That is, when the two input registers are the same we can use the shorter 
> CNEG mnemonic
> with the inverse condition instead of the longer CSNEG instruction. Similarly 
> for the
> CSINV and CSINC instructions, they have shorter CINV and CINC forms.
> This patch adjusts the output templates to emit the preferred shorter 
> sequences when possible.
> 
> The new mnemonics are just aliases, they map down to the same instruction in 
> the end, so there
> are no performance or behaviour implications. But it does make the assembly a 
> bit more readable
> IMO, since:
> "cnegw27, w9, le"
> can be simply read as "if the condition is less or equal negate w9" instead 
> of the previous:
> "csnegw27, w9, w9, gt" where you have to remember which of the input 
> registers is negated.
> 
> 
> Bootstrapped and tested on aarch64-linux-gnu.
> Ok for trunk?
>
> diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
> index 77bc7cd..2e4b26c 100644
> --- a/gcc/config/aarch64/aarch64.md
> +++ b/gcc/config/aarch64/aarch64.md
> @@ -3090,7 +3090,12 @@ (define_insn "csinc3_insn"
>   (const_int 1))
> (match_operand:GPI 3 "aarch64_reg_or_zero" "rZ")))]
>""
> -  "csinc\\t%0, %3, %2, %M1"
> +  {
> +if (rtx_equal_p (operands[2], operands[3]))
> +  return "cinc\\t%0, %2, %m1";
> +else
> +  return "csinc\\t%0, %3, %2, %M1";
> +  }
>[(set_attr "type" "csel")]
>  )

I guess you do it this way rather than just adding a new alternative in
the pattern to avoid any chance of constraining the register allocator, but
would this not be more natural to read as an {r, r, r, 2} alternative, or
similar?

If you've given that some thought and decided it doesn't work for you,
then this is OK for trunk.

Thanks,
James