On Thu, Mar 12, 2020 at 07:42:30PM +0100, J.W. Jagersma wrote: > On 2020-03-12 16:32, Segher Boessenkool wrote: > > On Thu, Mar 12, 2020 at 02:08:18PM +0100, Richard Biener wrote: > >>> It wasn't clear from my message above, but: I was mostly worried about > >>> requiring the asm to treat memory operands in a certain way when the > >>> exception is thrown. IMO it would be better to say that the values of > >>> memory operands are undefined on the exception edge. > >> > >> Rather unspecified. So IMHO on the exception edge the asm() should > >> still appear as a def for all outputs so the compiler cannot derive any > >> actual values for them. That of course also means that they must not > >> appear to be must-defs since we may not DSE earlier stores for example. > > > > So make all outputs of an asm that may throw (w/ -fnon-call-exceptions) > > inout operands instead? That works for registers exactly the same, too? > > Should gcc do this or would it be the user's responsibility? For > memory operands I don't think anything changes if you replace "=m" by > "+m". However changing each "=r" to "+r" would certainly generate less > optimal code.
[ "+m"(x) means exactly the same as "=m"(x) : "m"(x) ] Yes, but this is required for all operands that could keep their old value on exceptions. Since this will only happen with -fnon-call-exceptions, which already has a significant performance cost, I don't think adding just a tiny bit more is so bad? The benefit is that all asm will work, the user cannot do this wrong anymore. Segher
