[Bug target/105733] riscv: Poor codegen for large stack frames

["vineetg at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105733

Vineet Gupta <vineetg at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vineetg at gcc dot gnu.org

--- Comment #4 from Vineet Gupta <vineetg at gcc dot gnu.org> ---
There has been good improvements in gcc codegen specially with commit below.

commit 6619b3d4c15cd754798b1048c67f3806bbcc2e6d
Author: Jivan Hakobyan <jivanhakobyan9@gmail.com>
Date:   Wed Aug 23 14:10:30 2023 -0600

    Improve quality of code from LRA register elimination

    This is primarily Jivan's work, I'm mostly responsible for the write-up and
    coordinating with Vlad on a few questions.

    On targets with limitations on immediates usable in arithmetic
instructions,
    LRA's register elimination phase can construct fairly poor code.

     Tip W/o commit 6619b3d4c    |         With 6619b3d4c   
                                 |
foo:                             | foo:
        li      t0,-4096         |      li      t0,-4096
        addi    t0,t0,2032       |      addi    t0,t0,2032
        li      a5,0             |
        li      a4,0             |
        add     sp,sp,t0         |      add     sp,sp,t0
        add     a4,a4,a5         |
        add     a5,a4,sp         |      add     a5,a5,a0
        add     a5,a5,a0         |
        li      t0,4096          |      li      t0,4096
        sb      zero,0(a5)       |      sb      zero,0(a5)
        addi    t0,t0,-2032      |      addi    t0,t0,-2032
        add     sp,sp,t0         |      add     sp,sp,t0
        jr      ra               |      jr      ra

We still have the weird LUI 4096 based constant construction. I have a patch to
avoid 4096 for certain ranges  [-4096,-2049] or [2048,4094] (cribbed from
llvm).
e.g. 2064 = 2047 + 17 and we could potentially "spread" the 2 parts over 2 adds
to SP, avoiding the LUI. However if a const costs more than 1 insn, gcc wants
to force it in a register rather than split the add operation into 2 adds with
the split constants.

expand_binop
  expand_binop_directly
       avoid_expensive_constant

/* X is to be used in mode MODE as operand OPN to BINOPTAB.  If we're
   optimizing, and if the operand is a constant that costs more than
   1 instruction, force the constant into a register and return that
   register.  Return X otherwise.  UNSIGNEDP says whether X is unsigned.  */