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
