[ARC PATCH] Add *extvsi_n_0 define_insn_and_split for PR 110717.

[Roger Sayle]

Hi Jeff,
Doh!  Great catch.  The perils of not (yet) being able to actually
run any ARC execution tests myself.

> Shouldn't operands[4] be GEN_INT ((HOST_WIDE_INT_1U << tmp) - 1)?
Yes(-ish), operands[4] should be GEN_INT(HOST_WIDE_INT_1U << (tmp - 1)).

And the 32s in the test cases need to be 16s (the MSB of a five bit field is 16).

You're probably also thinking the same thing that I am... that it might be possible
to implement this in the middle-end, but things are complicated by combine's
make_compound_operation/expand_compound_operation, and that
combine doesn't (normally) like turning two instructions into three.

Fingers-crossed the attached patch works better on the nightly testers.

Thanks in advance,
Roger
--

> -----Original Message-----
> From: Jeff Law <jeffreyalaw@gmail.com>
> Sent: 07 December 2023 14:47
> To: Roger Sayle <roger@nextmovesoftware.com>; gcc-patches@gcc.gnu.org
> Cc: 'Claudiu Zissulescu' <claziss@gmail.com>
> Subject: Re: [ARC PATCH] Add *extvsi_n_0 define_insn_and_split for PR 110717.
> 
> On 12/5/23 06:59, Roger Sayle wrote:
> > This patch improves the code generated for bitfield sign extensions on
> > ARC cpus without a barrel shifter.
> >
> >
> > Compiling the following test case:
> >
> > int foo(int x) { return (x<<27)>>27; }
> >
> > with -O2 -mcpu=em, generates two loops:
> >
> > foo:    mov     lp_count,27
> >          lp      2f
> >          add     r0,r0,r0
> >          nop
> > 2:      # end single insn loop
> >          mov     lp_count,27
> >          lp      2f
> >          asr     r0,r0
> >          nop
> > 2:      # end single insn loop
> >          j_s     [blink]
> >
> >
> > and the closely related test case:
> >
> > struct S { int a : 5; };
> > int bar (struct S *p) { return p->a; }
> >
> > generates the slightly better:
> >
> > bar:    ldb_s   r0,[r0]
> >          mov_s   r2,0    ;3
> >          add3    r0,r2,r0
> >          sexb_s  r0,r0
> >          asr_s   r0,r0
> >          asr_s   r0,r0
> >          j_s.d   [blink]
> >          asr_s   r0,r0
> >
> > which uses 6 instructions to perform this particular sign extension.
> > It turns out that sign extensions can always be implemented using at
> > most three instructions on ARC (without a barrel shifter) using the
> > idiom ((x&mask)^msb)-msb [as described in section "2-5 Sign Extension"
> > of Henry Warren's book "Hacker's Delight"].  Using this, the sign
> > extensions above on ARC's EM both become:
> >
> >          bmsk_s  r0,r0,4
> >          xor     r0,r0,32
> >          sub     r0,r0,32
> >
> > which takes about 3 cycles, compared to the ~112 cycles for the loops
> > in foo.
> >
> >
> > Tested with a cross-compiler to arc-linux hosted on x86_64, with no
> > new (compile-only) regressions from make -k check.
> > Ok for mainline if this passes Claudiu's nightly testing?
> >
> >
> > 2023-12-05  Roger Sayle<roger@nextmovesoftware.com>
> >
> > gcc/ChangeLog
> >          * config/arc/arc.md (*extvsi_n_0): New define_insn_and_split to
> >          implement SImode sign extract using a AND, XOR and MINUS sequence.
> >
> > gcc/testsuite/ChangeLog
> >          * gcc.target/arc/extvsi-1.c: New test case.
> >          * gcc.target/arc/extvsi-2.c: Likewise.
> >
> >
> > Thanks in advance,
> > Roger
> > --
> >
> >
> > patchar.txt
> >
> > diff --git a/gcc/config/arc/arc.md b/gcc/config/arc/arc.md index
> > bf9f88eff047..5ebaf2e20ab0 100644
> > --- a/gcc/config/arc/arc.md
> > +++ b/gcc/config/arc/arc.md
> > @@ -6127,6 +6127,26 @@ archs4x, archs4xd"
> >     ""
> >     [(set_attr "length" "8")])
> >
> > +(define_insn_and_split "*extvsi_n_0"
> > +  [(set (match_operand:SI 0 "register_operand" "=r")
> > +	(sign_extract:SI (match_operand:SI 1 "register_operand" "0")
> > +			 (match_operand:QI 2 "const_int_operand")
> > +			 (const_int 0)))]
> > +  "!TARGET_BARREL_SHIFTER
> > +   && IN_RANGE (INTVAL (operands[2]), 2,
> > +		(optimize_insn_for_size_p () ? 28 : 30))"
> > +  "#"
> > +  "&& 1"
> > +[(set (match_dup 0) (and:SI (match_dup 0) (match_dup 3)))  (set
> > +(match_dup 0) (xor:SI (match_dup 0) (match_dup 4)))  (set (match_dup
> > +0) (minus:SI (match_dup 0) (match_dup 4)))] {
> > +  int tmp = INTVAL (operands[2]);
> > +  operands[3] = GEN_INT (~(HOST_WIDE_INT_M1U << tmp));
> > +  operands[4] = GEN_INT (HOST_WIDE_INT_1U << tmp);
> Shouldn't operands[4] be GEN_INT ((HOST_WIDE_INT_1U << tmp) - 1)?
> Otherwise it's flipping the wrong bit AFAICT.
> 
> H8 can benefit from the same transformation which is how I found this little goof.
> It's not as big a gain as ARC, but it does affect one of those builtin-overflow tests
> which tend to dominate testing time on the H8.
> 
> jeff
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patcharb.txt
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20231207/3cc590b9/attachment-0001.txt>