> On 5 Sep 2025, at 08:46, Jakub Jelinek <ja...@redhat.com> wrote:
>
> On Fri, Sep 05, 2025 at 09:37:42AM +0200, Richard Biener wrote:
>> Yes. I'll note that while we fixed some issues with code motion across
>> possible exit points we do not have good means of testing for invalid
>> code motion of UB invoking stmts. Guessing from the ones that actually
>> caused traps the problem is likely bigger for UB causing stmts (I for
>> example fixed PRE for trap(), but not for general UB - we'd have to
>> avoid PREing all variable shifts or any signed arithmetic).
>>
>> For what you describe returns_twice would work given it adds an
>> incoming edge, making the call first in a BB. This prevents any
>> code motion upwards, it doesn't require us to classify stmts into
>> those we can speculate and those we can't. On RTL a BARRIER
>> might do the trick?
>
> BARRIER in RTL is like __builtin_unreachable (), so the observable
> checkpoint certainly can't be represented like that.
> Anyway, my point is that one call call std::observable_checkpoint ()
> or exit (0) in any external function (unless say some standard describes
> what the function does), so we really should be creating any non-builtin
> call we know nothing about like that.
A volatile read would work, I guess - but the issue then is where to read
from - the intent of the paper is to generate no code, i.e. that the function
is only there for it’s effect as a checkpoint.
Iain
> Jakub
>
