On Tue, Mar 17, 2020 at 03:32:34PM +0000, Michael Matz wrote: > On Mon, 16 Mar 2020, Richard Sandiford wrote: > > 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. > > Well, it's both: on the exception path the compiler has to assume that the > the value wasn't changed (so that former defines are regarded as dead) or > that it already has changed (so that the effects the throwing > "instruction" had on the result (if any) aren't lost). The easiest for > this is to regard the result place as also being an input. > > (If broadened to all instructions under -fnon-call-exceptions, and not > just to asms will have quite a bad effect on optimization capabilities, > but I believe with enough force it's already possible now to construct > miscompiling testcases with the right mixtures of return types and ABIs)
It's a tradeoff: do we want this to work for almost no one and get PRs that we cannot solve, or do we generate slightly worse assembler code for -fnon-call-exceptions? I don't think this is a difficult decision to make, considering that you already get pretty bad performance with that flag (if indeed it works correctly at all). Segher
