John,
Here’s what I’m getting at
“Poison” is an attribute of a “value”, not a “value” itself.
“Poison” is an analysis result, and we should think about implementing it as such,
just like we do constant and range analysis.
Turning “poison” into a “value” means all “values” now have in addition to
a bit pattern an extra attribute (IE a tag).
Peter Lawrence.
I don't disagree with this but I don't see the concrete proposal yet.
John
You can think of poison as of just an extra element added to the type (e.g. to the set represented by i32 or i1). Only freezing it will replace it with something concrete such that if x is poison then freeze(x) == freeze(x), etc.
Why do you insist on treating it as an attribute? It's more like NaN for floating point: "not a value".
-Krzysztof
I'm guessing here---are you thinking of "could-be-poison" as opposed to "is-poison"?
-Krzysztof
As I understand (others have better thoughts on this than I do) it is difficult to make the "definitely not poison" analysis return useful answers very much of the time. Instead, we try to write transformations that work regardless of whether a value is poisoned.
John
Only freezing it will
replace it with something concrete such that if x is poison then
freeze(x) == freeze(x), etc.
Nit: it's not true that freeze(x) == freeze(x) in the current proposal. Each freeze can choose its own value.
John
Just for my understanding: Freeze is an instruction isn't it? So this example has to read either:
%a = freeze(poison)
%b = freeze(poison)
%cond = icmp eq %a, %b
then %cond isn't necessarily true (and also not necessarily false).
While:
%a = freeze(poison)
%cond = icmp eq %a, %a
is always true. Right?
- Matthias
Right!
John