Hello, On Wed, 18 Mar 2020, Segher Boessenkool 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). Oh, I wasn't advocating doing anything else than you suggested (i.e. make all operands in-out), I merely pointed out that the inherent problem here is not really specific to asms. Ciao, Michael.
