Peter Lawrence via llvm-dev
2017-Jun-16 15:01 UTC
[llvm-dev] 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.
John Regehr via llvm-dev
2017-Jun-16 15:20 UTC
[llvm-dev] a tagged architecture, the elephant in the undef / poison room
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 >
Krzysztof Parzyszek via llvm-dev
2017-Jun-16 15:36 UTC
[llvm-dev] a tagged architecture, the elephant in the undef / poison room
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
Krzysztof Parzyszek via llvm-dev
2017-Jun-16 15:41 UTC
[llvm-dev] a tagged architecture, the elephant in the undef / poison room
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
John Regehr via llvm-dev
2017-Jun-16 19:31 UTC
[llvm-dev] a tagged architecture, the elephant in the undef / poison room
> 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
Seemingly Similar Threads
- A tagged architecture, the elephant in the undef / poison room
- a tagged architecture, the elephant in the undef / poison room
- the root cause is CP, was: A tagged architecture, the elephant in the undef / poison room
- the root cause is CP, was: A tagged architecture, the elephant in the undef / poison room
- RFC: Killing undef and spreading poison