On 2020-03-19 00:56, Segher Boessenkool wrote:
> 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).

I just realized that changing all outputs to in+out would generate
worse code for *every* single asm that has any outputs.  Whereas
changing outputs to a temporary will not generate any extra code if
there is no local try/catch block.  I think that is something that
should be considered.

Then again, if the consensus is that outputs should become in+out, I
will implement that.  Then there is the issue of those debug stmts
being inserted after asms.  I can either patch the code that inserts
these (in tree-into-ssa.c) as I did earlier, or change the verify
routines to ignore debug stmts and the end of a basic block.  Which
would be preferable?

Reply via email to