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

[Jeff Law <law@redhat.com>]

On 03/05/2018 11:30 AM, Michael Matz wrote:
> Hi,
> 
> On Wed, 28 Feb 2018, Jeff Law wrote:
> 
>> The single successor test was strictly my paranoia WRT abnormal/EH edges.
>>
>> I don't immediately see why the CFG would be incorrect if the successor
>> of the setjmp block has multiple preds.
> 
> Actually, without further conditions I don't see how it would be safe for 
> the successor to have multiple preds.  We might have this situation:
> 
> bb1: ret = setjmp
> bb2: x0 = phi <x1 (bb1), foo(bbX)>
No.  Can't happen -- we're still building the initial CFG.  There are no
PHI nodes, there are no SSA_NAMEs.

We have two choices we can either target the setjmp itself, which is
what we've been doing and is inaccurate.  Or we can target the point
immediately after the setjmp, which is accurate.

After we have created the CFG, we'll proceed to build dominance
frontiers, compute lifetimes, etc that are nececessary to place the PHI
nodes.




> 
> As you noted the second "return" from setjmp is precisely after the setjmp 
> call itself, i.e. on the edge bb1->bb2.  Simply regarding it as landing at 
> the start of bb2 it becomes unclear from which edge bb2 was entered and 
> hence the runtime model of PHI nodes breaks down.
?!?    Again, we don't have PHIs and we're not simply regarding the
setjmp as landing at the start of BB2.  We are creating an edge from the
dispatcher to BB2.


Jeff