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

[Andrew MacLeod]

On 5/31/19 6:00 PM, Jeff Law wrote:
> 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?
oh we're getting into the weeds :-)
the program dies if *p ever gets executed and p is NULL.    so if we 
write shardedvar = 10 because we know this, does that make the program 
wrong if p is NULL?   I dunno. maybe I suppose some other thread starts 
doing something when it sees 20 and knows this one is going to die.. and 
now it wont know its going to die.  What a screwed up program :-).


>
> 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
yeah,  we may not be able to optimistically back propagate. I was 
thinking about it,  and what happens if you tried to push that 
non-nullness back into previous blocks. you can get into trouble quickly 
:-)Â  so it does seem like it might be important to maintain the temporal 
integrity of a range when any kind of inferred knowledge like *p or  /x 
is applied to it.

This is not a pressing issue yet since we arent trying to immediately 
integrate the on-demand engine.  I'll mull it over some more, but we may 
be able to do some processing for blocks in which there is an issue with 
non-zeroness as needed..  And the fallback to fully enumerate and  
forward process any block affected should certainly work and not cost 
more than the current mechanism which does the same thing.


Andrew