Segher Boessenkool <seg...@kernel.crashing.org> writes: > On Mon, Mar 16, 2020 at 05:47:03PM +0000, Richard Sandiford wrote: >> Segher Boessenkool <seg...@kernel.crashing.org> writes: >> >> we do delete "x = 1" for f1. I think that's the expected behaviour. >> >> We don't yet delete the initialisation in f2, but I think in principle >> >> we could. >> > >> > Right. And this is incorrect if the asm may throw. >> >> Well... >> >> >> So the kind of contract I was advocating was: >> >> >> >> - the compiler can't make any assumptions about what the asm does >> >> or doesn't do to output operands when an exception is raised >> >> >> >> - the source code can't make any assumption about the values bound >> >> to output operands when an exception is raised >> >> ...with this interpretation, the deletions above would be correct even >> if the asm throws. > > The write to "x" *before the asm* is deleted. I cannot think of any > interpretation where that is correct (this does not involve inline asm > at all: it is deleting an observable side effect before the exception).
It's correct under the contract above :-) >> > And the easiest (and only feasible?) way to do this is for the compiler >> > to automatically make an input for every output as well, imo. >> >> Modifying the asm like that feels a bit dangerous, > > Yes, obviously. The other option is to accept that almost all existing > inline asm will have UB, with -fnon-call-exceptions. I think that is > an even less desirable option. > >> And the other problem >> still exists: he compiler might assume that the output isn't modified >> unless the asm completes normally. > > I don't understand what this means? As far as the compiler is concerned > any asm is just one instruction? And it all executes completely always. > You need to do things with the constraints to tell the compiler it does > not know some of the values around. If you have both an input and an > output for a variable, the compiler does not know what value is written > to it, and it might just be the one that was the input already (which is > the same effect as not writing it at all). Normally, for SSA names in something like: _1 = foo () the definition of _1 does not take place when foo throws. Similarly for non-call exceptions on other statements. It sounds like what you're describing requires the corresponding definition to happen for memory outputs regardless of whether the asm throws or not, so that the memory appears to change on both excecution paths. Otherwise, the compiler would be able to assume that the memory operand still has its original value in the exception handler. Richard
