[Bug target/84790] Miscompilation for MIPS16 with -fpic and -Os or -O2

["mschiffer@universe-factory.net" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #13 from Matthias Schiffer <mschiffer@universe-factory.net> ---
I don't think the register used matters -  changing it may hide the bug in
specific instances, but it does not fix the root cause.

I've now built a simpler reproducer which still seems to exhibit the same issue
with your latest patch (however I've only built a baremetal GCC with your patch
and looked at the generated code, I've not actually run this example on the
affected platforms - I might be overlooking something. Will try to get a full
toolchain build in the next days).

The basic premise of the following code:

In test(), the return value `ret` must be moved from v0 to a different register
temporarily for calling foo(). Using the inline asm, GCC is nudged to use v1 as
this temporary register.

As GCC knows the contents of foo() and bar(), it assumes that the value of v1
is preserved across the call to foo(). This assumption is wrong because the gp
setup code is inserted at the beginning of bar after all optimization and
register allocation has already happened. As mentioned before, this setup code
clobbers v1.

```
unsigned ext(void);

__attribute__((noinline))
static void foo(void) {
        /* Do not let the optimizer remove foo and bar */
        asm volatile("");
}

__attribute__((noinline))
static void bar(void) {
        foo();
}

unsigned test(void)
{
        unsigned ret = ext();

        register unsigned v1 asm("v1") = ret;
        asm volatile("" :: "r"(v1));

        bar();

        return ret;
}
```

`objdump -d -r` output (built using GCC commit
05daf617ea22e1d818295ed2d037456937e23530, with "-Os -mips32r2 -mtune=24kc
-mabicalls -mips16 -fpic"):

```
Disassembly of section .text:

00000000 <foo>:
   0:   e8a0            jrc     ra
   2:   6500            nop

00000004 <bar>:
   4:   f000 6a00       li      v0,0
                        4: R_MIPS16_HI16        _gp_disp
   8:   f000 0b00       la      v1,8 <bar+0x4>
                        8: R_MIPS16_LO16        _gp_disp
   c:   f400 3240       sll     v0,16
  10:   e269            addu    v0,v1
  12:   64c4            save    32,ra
  14:   659a            move    gp,v0
  16:   d204            sw      v0,16(sp)
  18:   675c            move    v0,gp
  1a:   f000 9a40       lw      v0,0(v0)
                        1a: R_MIPS16_GOT16      foo
  1e:   f000 4a00       addiu   v0,0
                        1e: R_MIPS16_LO16       foo
  22:   ea40            jalr    v0
  24:   653a            move    t9,v0
  26:   6444            restore 32,ra
  28:   e8a0            jrc     ra
  2a:   6500            nop

0000002c <test>:
  2c:   f000 6a00       li      v0,0
                        2c: R_MIPS16_HI16       _gp_disp
  30:   f000 0b00       la      v1,30 <test+0x4>
                        30: R_MIPS16_LO16       _gp_disp
  34:   f400 3240       sll     v0,16
  38:   e269            addu    v0,v1
  3a:   659a            move    gp,v0
  3c:   64e4            save    32,ra,s0
  3e:   671c            move    s0,gp
  40:   d204            sw      v0,16(sp)
  42:   f000 9840       lw      v0,0(s0)
                        42: R_MIPS16_CALL16     ext
  46:   ea40            jalr    v0
  48:   653a            move    t9,v0
  4a:   6762            move    v1,v0
  4c:   f000 9800       lw      s0,0(s0)
                        4c: R_MIPS16_GOT16      bar
  50:   f000 4800       addiu   s0,0
                        50: R_MIPS16_LO16       bar
  54:   e840            jalr    s0
  56:   6538            move    t9,s0
  58:   6464            restore 32,ra,s0
  5a:   e820            jr      ra
  5c:   6743            move    v0,v1
  5e:   6500            nop
```

At 4a, the return value is moved to v1. At 5c, it is supposed to be moved back,
but v1 has been clobbered in the mean time.