Re: On-Demand range technology [2/5] - Major Components : How it works

[Jeff Law <law@redhat.com>]

On 5/31/19 2:26 PM, Andrew MacLeod wrote:
> On 5/31/19 2:16 PM, Jeff Law wrote:
>> On 5/31/19 9:40 AM, Andrew MacLeod wrote:
>>>> stmt-level tracking of ranges are sometimes important.  This is
>>>> something the machinery cannot provide - correct?  At least not
>>>> optimistically enough with ranges derived about uses.
>>> Maybe I'm the one missing something, but in the absence of statement
>>> level exception throwing via 'can_throw_non_call_exceptions' being true,
>>> any assertion made anywhere in the block to an ssa_name applies to the
>>> entire block does it not?   ie it doesn't matter if the deference
>>> happens first thing in the block or last thing, its not going to change
>>> its value within the block.. its going to be non-null throughout the
>>> entire block.
>> No, I don't think it can hold for the entire block.
>>
>> Consider
>>
>>    x = p ? 10 : 20;
>>    foo (x)
>>    *p = whatever
>>
>> We don't know p is non-null because foo might not return.  If by way of
>> the dereference we were to assert p is non-null for the entire block,
>> then we'd pass the wrong value to foo().
>>
>> Jeff
>>
> 
> Interesting.  I started wondering about calls when I was talking about
> non-call exceptions, but couldn't think of an example off the top of my
> head.
> 
> OK, so the statement holds true for any section of code without calls in
> it.  If the block is marked as having a non-null deref in it, I need to
> look at statement in between the relevant def and use to see if there is
> an impact rather than just checking the flag.  If the flag is false, we
> need to do nothing else.
What about in a multi-threaded application?   No calls here....

  x = p ? 10 : 20;
  sharedvar = x;
  [ bunch of straightline code]
  *p = <whatever>

Our thread gets preempted and for some reason never restarts?  Another
thread could read sharedvar and get the wrong value?

But one might argue we have similar problems in other places where we
"back propagate" non-nullness.  I'm thinking about cases where the
pointer is passed to a function in an argument slot marked as non-null.
 We mark the name as currently having a non-null value and it can get
back propagated around in rather surprising ways and we've been called
out on it.

Dunno...  Probably worth mulling over some more...
Jeff