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

Andrew Pinski pinskia@gmail.com
Sat Sep 12 02:04:00 GMT 2015

On Tue, Sep 1, 2015 at 6:08 PM, Kyrill Tkachov <kyrylo.tkachov@arm.com> wrote:
> Hi all,
> The ARMv8-A reference manual says:
> "CNEG <Wd>, <Wn>, <cond>
> is equivalent to
> CSNEG <Wd>, <Wn>, <Wn>, invert(<cond>)
> 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:
> "cneg    w27, w9, le"
> can be simply read as "if the condition is less or equal negate w9" instead
> of the previous:
> "csneg    w27, 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.

Andrew Pinski

> Thanks,
> Kyrill
> 2015-09-01  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>
>     * config/aarch64/aarch64.md (csinc3<mode>_insn): Use CINC
>     mnemonic when possible.
>     (*csinv3<mode>_insn): Use CINV mnemonic when possible.
>     (csneg3<mode>_insn): USE CNEG mnemonic when possible.
> 2015-09-01  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>
>     * 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.

More information about the Gcc-patches mailing list