On Fri, Sep 5, 2025 at 10:07 AM Jakub Jelinek <ja...@redhat.com> wrote: > > On Fri, Sep 05, 2025 at 08:51:10AM +0100, Iain Sandoe wrote: > > > 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. > > I think a volatile read is not sufficient for preventing time travel. > I think a CALL_INSN is safe (exactly because it could have done exit (0) > or std::observable_checkpoint () inside of it where the compiler doesn't see > it) but in RTL has the major disadvantage (even if optimized away during > final) that RA clobbers all call clobbered registers there. > I wonder if we treat a volatile asm similarly (especially with "memory" > clobber), because it actually might contain a call, though obviously RA > doesn't add the cost of clobbering call clobbered registers there (if one > calls from inline asm, one needs to save/restore those registers or use > a different ABI with no call clobbered registers or only the ones specified > in clobbers of the inline asm). And inline asm can expand to nothing or > almost nothing (the latter if it has inputs/outputs, but this one doesn't > need any, just "memory").
Just to agree - a call is safe modulo bugs in GCC. A returns-twice call is "safer" because it avoids a certain class of bugs in GCC. On RTL there isn't much UB and UB exploiting cases left - it should be mostly reads from uninitialized storage, so a memory barrier should work there. TBAA might be another thing, but again a memory barrier should be OK. Richard. > Jakub >
