https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |missed-optimization
CC| |rguenth at gcc dot gnu.org
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
'enhancement' Importance is the magic we use, in the end it's a missed
optimization since you refer to sub-optimal code gen.
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?
"recoverable" likely means resuming after the trap, not on an exception
path (so it'll not be a throw())?
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]
