[PATCH v3 1/2] generate EH info for volatile asm statements (PR93981)

[Jeff Law]

On 11/13/20 1:45 AM, Richard Biener wrote:
> On Thu, Nov 12, 2020 at 4:53 PM Jeff Law via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
>>
>> On 3/11/20 6:38 PM, J.W. Jagersma via Gcc-patches wrote:
>>> The following patch extends the generation of exception handling
>>> information, so that it is possible to catch exceptions thrown from
>>> volatile asm statements, when -fnon-call-exceptions is enabled.  Parts
>>> of the gcc code already suggested this should be possible, but it was
>>> never fully implemented.
>>>
>>> Two new test cases are added.  The target-dependent test should pass on
>>> platforms where throwing from a signal handler is allowed.  The only
>>> platform I am aware of where that is the case is *-linux-gnu, so it is
>>> set to XFAIL on all others.
>>>
>>> gcc/
>>> 2020-03-11  Jan W. Jagersma  <jwjagersma@gmail.com>
>>>
>>>       PR inline-asm/93981
>>>       * tree-cfg.c (make_edges_bb): Make EH edges for GIMPLE_ASM.
>>>       * tree-eh.c (lower_eh_constructs_2): Add case for GIMPLE_ASM.
>>>       Assign register output operands to temporaries.
>>>       * doc/extend.texi: Document that volatile asms can now throw.
>>>
>>> gcc/testsuite/
>>> 2020-03-11  Jan W. Jagersma  <jwjagersma@gmail.com>
>>>
>>>       PR inline-asm/93981
>>>       * g++.target/i386/pr93981.C: New test.
>>>       * g++.dg/eh/pr93981.C: New test.
>> Is this the final version of the patch?  Do we have agreement on the
>> sematics for output operands, particularly memory operands?  The last
>> few messages in the March thread lead me to believe that's still not
>> settled.
> I think it's up to the asm itself to put the correct contents.  For the
> cases where GCC needs to emit copies from outputs (that is,
> if it ever reloads them) the only sensible thing is that those are
> not emitted on the EH edge but only on the fallthru one.
On the non-EH edge everything should work as expected.

We can't know where in the ASM where the throw occurred and we don't
model what happens inside the ASM.  I think that combination inherently
means we have no way to reliably know the state any output operand on
the EH edge. 

>
> On GIMPLE this cannot be represented but it means that
> SSA uses of asm defs may not appear on the EH edge
> (I do have some checking patch for this somewhere which
> I think catches one or two existing problems).
Right.  I do wonder if we should have a clobber of the output operands
that are gimple registers on the EH edge though.  I think that most
closely matches the actual semantics.  A checker could see if there's
any SSA_NAME uses that are reached by one of those clobbers.  I think
all you and I aren't in agreement on is whether to issue the clobber on
the EH edge or not and the implications for how we'd check for this case.



>   On RTL if
> the outputs are registers we cannot do any such checking
> of course (no SSA form) and whether the old or the "new"
> value lives is an implementation detail of the asm itself.
Agreed.  I don't see a way to check this in RTL.   I'd like to hope that
if we catch it in gimple that it wouldn't ever be an issue in RTL.   But
I'm sure there'd be some path where it could sneak through ;(

jeff