llvm dev - Jun 2017 - 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


On 6/16/17 9:01 AM, Peter Lawrence wrote:
> 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.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

On 6/16/2017 10:01 AM, Peter Lawrence via llvm-dev
wrote:
> “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.
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

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation

On 6/16/2017 10:36 AM, Krzysztof Parzyszek via llvm-dev
wrote:
> On 6/16/2017 10:01 AM, Peter Lawrence via llvm-dev wrote:
>> “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.
> 
> Why do you insist on treating it as an attribute? It's more like NaN
for
> floating point: "not a value".
I'm guessing here---are you thinking of "could-be-poison" as
opposed to
"is-poison"?

-Krzysztof

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation

> 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