internal-fn: Call do_pending_stack_adjust in expand_SPACESHIP [PR104679]
authorJakub Jelinek <jakub@redhat.com>
Fri, 25 Feb 2022 09:56:46 +0000 (10:56 +0100)
committerJakub Jelinek <jakub@redhat.com>
Fri, 25 Feb 2022 09:56:46 +0000 (10:56 +0100)
commit526fbcfa636fb7e544c1ad69101dbccecbee8b28
tree762e55a6b7eacc520d5aa50f929ad77752a26715
parent758671b88b78d7629376b118ec6ca6bcfbabbd36
internal-fn: Call do_pending_stack_adjust in expand_SPACESHIP [PR104679]

The following testcase is miscompiled on ia32 at -O2, because
when expand_SPACESHIP is called, we have pending stack adjustment
from the foo call right before it.
Now, ix86_expand_fp_spaceship uses emit_jump_insn several times
but then emit_jump also several times.  While emit_jump_insn doesn't
do do_pending_stack_adjust (), emit_jump does, so we end up with:
...
    8: call [`_Z3foodl'] argc:0x10
      REG_CALL_DECL `_Z3foodl'
    9: r88:DF=[`a']
   10: r89:HI=unspec[cmp(r88:DF,0.0)] 25
   11: flags:CC=unspec[r89:HI] 26
   12: pc={(unordered(flags:CCFP,0))?L27:pc}
      REG_BR_PROB 536868
   66: NOTE_INSN_BASIC_BLOCK 4
   13: pc={(uneq(flags:CCFP,0))?L19:pc}
      REG_BR_PROB 214748364
   67: NOTE_INSN_BASIC_BLOCK 5
   14: pc={(flags:CCFP>0)?L23:pc}
      REG_BR_PROB 536870916
   68: NOTE_INSN_BASIC_BLOCK 6
   15: r86:SI=0xffffffffffffffff
   16: {sp:SI=sp:SI+0x10;clobber flags:CC;}
      REG_ARGS_SIZE 0
   17: pc=L29
   18: barrier
   19: L19:
   69: NOTE_INSN_BASIC_BLOCK 7
...
The sp += 16 pending stuck adjust was emitted in the middle of the
sequence and is effective only for the single case of the 4 possibilities
where .SPACESHIP returns -1, in all other cases the stack isn't adjusted
and so we ICE during dwarf2cfi.

Now, we could either call do_pending_stack_adjust in
ix86_expand_fp_spaceship, or use there calls that actually don't call
do_pending_stack_adjust (but having the stack adjustment across branches is
generally undesirable), or we can call it in expand_SPACESHIP for all
targets (note, just i386 currently implements it).
I chose the generic code because e.g. expand_{addsub,neg,mul}_overflow
in the same file also call do_pending_stack_adjust in internal-fn.cc for the
same reasons, that it is expected that most if not all targets will expand
those through jumps and we don't want all of the targets to need to deal
with that.

2022-02-25  Jakub Jelinek  <jakub@redhat.com>

PR middle-end/104679
* internal-fn.cc (expand_SPACESHIP): Call do_pending_stack_adjust.

* g++.dg/torture/pr104679.C: New test.
gcc/internal-fn.cc
gcc/testsuite/g++.dg/torture/pr104679.C [new file with mode: 0644]