similar to: [LLVMdev] poison and select

On 01/28/2015 07:02 AM, Sean Silva wrote: > Could you maybe provide an example where replacing `%always_poison` > with `undef` will change the meaning? At least for me, the thing that > I'm most unclear about is how poison differs from undef. I will second this request for much the same reason. > > -- Sean Silva > > On Wed, Jan 28, 2015 at 2:50 AM, David Majnemer >

Hello, What follows is my attempt to describe how poison works. Let me know what you think. -- David # LLVM Poison Semantics Poison is an LLVM concept which exists solely to enable further optimization of LLVM IR. The exact behavior of poison has been, to say the least, confusing for users, researchers and engineers working with LLVM. This document hopes to clear up some of the confusion

> Poison is a flawed concept. I proved it was flawed back in 2011 [0] Nice. My colleagues and I will dig through this material and possibly come back with some ideas. We're going to need some sort of semantics for UB in LLVM since otherwise these formal-methods-based tools like Souper and Alive risk not making sense. Thanks, John

While looking at optimizations where Souper exploits known bits, I realized that it would be easy to teach Souper to compute known bits. Comparing its results against computeKnownBits() from r246393, it looks like there are some easy (and some not-easy) opportunities for improvement, please see a few examples below. The expressions come from compiling LLVM itself. Happily, this exercise

On the subject of undefined behavior and known bits, as I'm sure some of you are aware, code in ValueTracking.cpp is exploiting poison value rules to get a bit of extra precision in the known bits. These rules fire on examples like the ones below. Do we have a set of rules that clients of known bits need to follow to avoid unsoundness? I remember Nuno and/or David Majnemer saying

On Tue, Jan 27, 2015 at 7:23 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi David, > > I spent some time thinking about poison semantics this way, but here > is where I always get stuck: > > Consider the IR fragment > > %x = zext i32 %maybe_poison to i64 > %y = lshr i64 %x 32 > %ptr = gep %global, %y > store 42 to %ptr > > If

On Tue, Feb 3, 2015 at 3:15 AM, Nuno Lopes <nuno.lopes at ist.utl.pt> wrote: > Hi, > > > > Thanks David for putting up this proposal together! > > I like the idea of having poison values behave more like undef (i.e., per > bit, with run-time behavior). > > One of the problems this proposal solves is speculation of 'a && b' into > 'a &

From: Alexander Duyck <alexander.h.duyck at linux.intel.com> If we have free page hinting or page reporting enabled we should disable it if the pages are poisoned or initialized on free and we cannot notify the hypervisor. Fixes: 5d757c8d518d ("virtio-balloon: add support for providing free page reports to host") Signed-off-by: Alexander Duyck <alexander.h.duyck at

From: Alexander Duyck <alexander.h.duyck at linux.intel.com> If we have free page hinting or page reporting enabled we should disable it if the pages are poisoned or initialized on free and we cannot notify the hypervisor. Fixes: 5d757c8d518d ("virtio-balloon: add support for providing free page reports to host") Signed-off-by: Alexander Duyck <alexander.h.duyck at

On Thu, Apr 16, 2020 at 3:13 PM Michael S. Tsirkin <mst at redhat.com> wrote: > > On Thu, Apr 16, 2020 at 12:30:38PM -0700, Alexander Duyck wrote: > > From: Alexander Duyck <alexander.h.duyck at linux.intel.com> > > > > If we have free page hinting or page reporting enabled we should disable it > > if the pages are poisoned or initialized on free and we

From: Alexander Duyck <alexander.h.duyck at linux.intel.com> We should disable free page reporting if page poisoning is enabled in the kernel but we cannot report it via the balloon interface. This way we can avoid the possibility of corrupting guest memory. Normally the page poison reporting feature should always be present when free page reporting is enabled on the hypervisor, however

From: Alexander Duyck <alexander.h.duyck at linux.intel.com> We should disable free page reporting if page poisoning is enabled in the kernel but we cannot report it via the balloon interface. This way we can avoid the possibility of corrupting guest memory. Normally the page poison reporting feature should always be present when free page reporting is enabled on the hypervisor, however

On 17.04.20 08:28, Michael S. Tsirkin wrote: > On Thu, Apr 16, 2020 at 04:52:42PM -0700, Alexander Duyck wrote: >> On Thu, Apr 16, 2020 at 3:13 PM Michael S. Tsirkin <mst at redhat.com> wrote: >>> >>> On Thu, Apr 16, 2020 at 12:30:38PM -0700, Alexander Duyck wrote: >>>> From: Alexander Duyck <alexander.h.duyck at linux.intel.com> >>>>

On Mon, Apr 27, 2020 at 1:08 AM David Hildenbrand <david at redhat.com> wrote: > > On 24.04.20 18:24, Alexander Duyck wrote: > > From: Alexander Duyck <alexander.h.duyck at linux.intel.com> > > > > We should disable free page reporting if page poisoning is enabled in the > > kernel but we cannot report it via the balloon interface. This way we can >

On Mon, Apr 27, 2020 at 1:08 AM David Hildenbrand <david at redhat.com> wrote: > > On 24.04.20 18:24, Alexander Duyck wrote: > > From: Alexander Duyck <alexander.h.duyck at linux.intel.com> > > > > We should disable free page reporting if page poisoning is enabled in the > > kernel but we cannot report it via the balloon interface. This way we can >

>>> Now we are talking about what's safe to do with the page. >>> >>> If POISON flag is set by hypervisor but clear by guest, >>> or poison_val is 0, then it's clear it's safe to blow >>> away the page if we can figure out it's unused. >>> >>> Otherwise, it's much less clear :) >> >> Hah! Agreed :D >

Hi all, I was initially going to send this email to a thread on llvm-commits where David explained the issue with poison and select to me, but then some quick googling led me to this thread. I've been thinking about a possible semantics for poison values in a certain way: The key semantic difference between undef and poison, as I understand it, is that when justifying an execution trace the

Today I ran into another aspect of the poison problem... Basically, SimplifyCFG wants to take expr1 && expr2 and flatten it into x = expr1 y = expr2 x&y This isn't safe when expr2 might execute UB. The consequence is that no LLVM shift instruction is safe to speculatively execute, nor is any nsw/nuw/exact variant, unless the operands can be proven to be in

If I got poison propagation right, it's probably only by luck! Hopefully, the funnel shift bug is fixed here: https://reviews.llvm.org/rL354905 Nuno, IIUC this means that you do *not* need to change the funnel shift semantics in Alive. So I think that means we're still on track to go with John's suggestion that only select and phi can block poison? (I don't know of any

Hello, I'd like to offer an alternative solution to the "poison problem": remove it. What follows is rather informal. I'd happily write up a nicer document if this RFC stands up to scrutiny. The idea was born from two observations: - undef was introduced to model a load of uninitialized memory, a form of undefined behavior. - poison was introduced to model integer overflow,