Re: [PING][PATCH] RISC-V: Avoid redundant sign-extension for SImode SGE, SGEU, SLE, SLEU

["Maciej W. Rozycki" <macro@embecosm.com>]

On Mon, 28 Nov 2022, Jeff Law wrote:

> > > > LGTM, but with a nit, I don't get set.w but get an andi like below, so
> > > > maybe we should also scan-assembler-not andi? feel free to commit that
> > > > directly with that fix
> > > > 
> > > > ```asm
> > > > sleu:
> > > >         sgtu    a0,a0,a1        # 9     [c=4 l=4]  *sgtu_disi
> > > >         xori    a0,a0,1 # 10    [c=4 l=4]  *xorsi3_internal/1
> > > >         andi    a0,a0,1 # 16    [c=4 l=4]  anddi3/1
> > > >         ret             # 25    [c=0 l=4]  simple_return
> > > > ```
> > >   Interesting.  I can do that, but can you please share the compilation
> > > options, given or defaulted (from `--with...' configuration options), this
> > > happens with?
> >   I have noticed it went nowhere.  Can you please check what compilation
> > options lead to this discrepancy so that we can have the fix included in
> > GCC 13?  I'd like to understand what's going on here.
> 
> FWIW, I don't see the redundant sign extension with this testcase at -O2 on
> the trunk.  Is it possible the patch has been made redundant over the last few
> months?

 Maybe at -O2, but the test cases continue to fail in my configuration for 
other optimisation levels:

FAIL: gcc.target/riscv/sge.c   -O1   scan-assembler-not sext\\.w
FAIL: gcc.target/riscv/sge.c  -Og -g   scan-assembler-not sext\\.w
FAIL: gcc.target/riscv/sgeu.c   -O1   scan-assembler-not sext\\.w
FAIL: gcc.target/riscv/sgeu.c  -Og -g   scan-assembler-not sext\\.w
FAIL: gcc.target/riscv/sle.c   -O1   scan-assembler-not sext\\.w
FAIL: gcc.target/riscv/sle.c  -Og -g   scan-assembler-not sext\\.w
FAIL: gcc.target/riscv/sleu.c   -O1   scan-assembler-not sext\\.w
FAIL: gcc.target/riscv/sleu.c  -Og -g   scan-assembler-not sext\\.w

when applied on top of:

$ riscv64-linux-gnu-gcc --version
riscv64-linux-gnu-gcc (GCC) 13.0.0 20221128 (experimental)

Not anymore with the whole patch applied.

 Does it make sense to bisect the change that removed the pessimisation at 
-O2 to understand what is going on here?

 I think my change is worthwhile anyway: why to rely on the optimiser to 
get things sorted while we can produce the best code in the backend right 
away in the first place?

  Maciej