Re: [RFA][PATCH][PR middle-end/61118] Improve tree CFG accuracy for setjmp/longjmp

[Jeff Law <law at redhat dot com>]

On 03/08/2018 06:22 AM, Richard Biener wrote:
> On Thu, Mar 8, 2018 at 1:54 PM, Michael Matz <matz@suse.de> wrote:
>> Hi,
>>
>> On Wed, 7 Mar 2018, Peter Bergner wrote:
>>
>>> On 3/7/18 12:01 AM, Jeff Law wrote:
>>>> I believe so by nature that the setjmp dominates the longjmp sites and
>>>> thus also dominates the dispatcher.  But it's something I want to
>>>> explicitly check before resubmitting.
>>>
>>> Are we sure a setjmp has to dominate its longjmp sites?
>>
>> No, they don't have to dominate.  For lack of better term I used something
>> like "ordered after" in my mails :)
>>
>>> Couldn't you have something like:
>>
>> Yeah, exactly.
> 
> So given all the discussion _iff_ we want to change the CFG we generate then
> let's invent a general __builtin_receiver () and lower setjmp to
And I'm seriously thinking we may want to hold off on the fix for 61118
for gcc-8.  We still might want to fix 21161 though.  I still need to
digest all the discussion.


> 
>   setjmp ();
>   res = __builtin_receiver ();
> 
> and construct a CFG around that.  Remember that IIRC I added the abnormal
> edges to and from setjmp to inhibit code-motion across it so whatever CFG
> we'll end up with should ensure that there can't be any code-motion optimization
> across the above pair nor "inbetween" it.  The straight-forward
> CFG of, apart from the fallthru from setjmp to the receiver, a abnormal edge
> to the dispatcher from setjmp and an abnormal edge from the dispatcher to
> the receiver would do that trick I think.
> 
> I'd rather not do that for GCC 8 though.  So to fix the warning can't we do
> sth else "good" and move the strange warning code from RTL to GIMPLE?
Someone mentioned that possibility in one of the related BZs.  The
concern was the factoring of the handler could really hinder good
dataflow analysis.  We could end up making things worse :(


> 
> Or re-do the warning?  Since in the other thread about setjmp side-effects
> we concluded that setjmp has to preserve all call-saved regs?  I don't see
> that reflected in regno_clobbered_at_setjmp or its caller -- that is,
> we should only warn for call clobbered and thus caller-saved regs because
> normal return may clobber the spilled values.
Possibly.  It's clear from the discussion and multitude of BZs that this
is complex and easily goof'd.

I believe part of the "trick" here is that once we compute (in RTL) the
set of objects live across the setjmp the allocators then refuse to
allocate those values into call-saved registers (hence the other
discussion thread) with Peter and co.  Of course the RTL analysis get
this wrong in a roughly similar manner (21161).


> Not sure if the PR testcase is amongst the cases fixed by such change.
Unclear -- it'd likely depend on where we do the analysis.  It's
certainly the case that for 61118 that if the analysis happens in RTL
and we haven't addressed our CFG correctness issues that we're going to
fail.

jeff.