# a tagged architecture, the elephant in the undef / poison room

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