Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)

[Richard Sandiford <richard.sandiford@arm.com>]

Thanks for doing this.

"J.W. Jagersma" <jwjagersma@gmail.com> writes:
> On 2020-03-07 20:20, Segher Boessenkool wrote:
>> Hi!
>> 
>> On Sat, Mar 07, 2020 at 06:12:45PM +0100, J.W. Jagersma wrote:
>>> The following patch extends the generation of exception handling
>>> information to cover volatile asms too.  This was already mostly
>>> implemented, and only minor changes are required in order to make it
>>> work.
>> 
>> This should wait for stage 1, IMO.  Looks pretty good to me, thanks!
>
> Hi, thanks for your response.
> What does stage 1 refer to?  I'm sorry, this is my first gcc patch and
> I'm still learning how this all works.
>
>> Some comments:
>> 
>>> +When non-call exceptions (@option{-fnon-call-exceptions}) are enabled, a
>>> +@code{volatile asm} statement is also allowed to throw exceptions.  If it
>>> +does, then the compiler assumes that its output operands have not been written
>>> +yet.
>> 
>> That reads as if the compiler assumes the outputs retain their original
>> value, but that isn't true (I hope!)  The compiler assumes the output
>> are clobbered, but it doesn't assume they are assigned any definite
>> value?
>
> Register outputs are assumed to be clobbered, yes.  For memory outputs
> this is not the case, if the asm writes it before throwing then the
> memory operand retains this value.  It should be the user's
> responsibility to ensure that an asm has no side-effects if it throws.

I guess one problem is that something like "=&m" explicitly says that
the operand is clobbered "early", and I think it would be fair for
"early" to include clobbers before the exception.  So IMO we should
allow at least early-clobbered memory outputs to be clobbered by the
exception.

And if we do that, then I'm not sure there's much benefit in trying to
treat the non-earlyclobber memory case specially.

It would be good to have testcases for the output cases.  E.g. for:

        int foo;
        int bar = 0;
        try
          {
            foo = 1;
            asm volatile ("..." : "=m" (foo));
          }
        catch (...whatever...)
          {
            bar = foo;
          }
        ...use bar...

What does "bar = foo" read?  Is it always undefined behaviour if executed?
Or does it always read "foo" from memory?  Can it be optimised to "bar = 1"?
Is "foo = 1" dead code?

Thanks,
Richard