[Bug middle-end/99299] Need a recoverable version of __builtin_trap()

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

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

--- Comment #6 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #4)
> I'm not sure what your proposed not noreturn trap() would do in terms of
> IL semantics compared to a not specially annotated general call?

Nothing I think?  But __builtin_trap *is* very different: it ends BBs.

> "recoverable" likely means resuming after the trap, not on an exception
> path (so it'll not be a throw())?

"recoverable" is super unclear.  For example, on Power the hardware has a
concept "recoverable interrupt", which set MSR[RI]=1, and traps never do.
This is a very different concept as what is wanted here, which has nothing
to do with recoverability, and is simply about not being an abort() (which
__builtin_trap *is*!)

> The only thing that might be useful to the middle-end would be marking
> the function as not altering the memory state.  But I suppose it should
> still serve as a barrier for code motion of both loads and stores, even
> of those loads/stores are known to not trap.  The only magic we'd have
> for this would be __attribute__((const,returns_twice)).  Which likely
> will be more detrimental to general optimization.
> 
> So - what's the "sub-optimal code generation" you refer to from the
> (presumably) volatile asm() you use for the trap?
> 
> [yeah, asm() on GIMPLE is less optimized than a call]

The rs6000 backend can optimise the used instructions: we have trap_if
instructions, both with registers and with immediates.  A single
instruction can do a comparison and a conditional trap.  This works great
with __builtin_trap, *if* the kernel's trap handler has abort() semantics.

__builtin_trap_no_abort() maybe?