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

[Richard Biener <richard dot guenther at gmail dot com>]

On March 9, 2018 8:42:16 PM GMT+01:00, Jeff Law <law@redhat.com> wrote:
>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.

Note that on RTL the CFG does not have any abnormal edges for setjmp and thus code is freely moved across it. Maybe addressing that would also help. 

Richard. 

>
>jeff.