similar to: [LLVMdev] The nsw story

A few thoughts from someone on the sidelines; hope they're helpful. On Tue, Nov 29, 2011 at 3:21 PM, Dan Gohman <gohman at apple.com> wrote: > The first solution for this was to define nsw add to return undef on > overflow, instead of invoking immediate undefined behavior. This way, > overflow can happen and it doesn't cause any harm unless the value > is actually used.

John, Sanjoy, Nuno, David, Thanks for the tip, below are the relevant posts from the archives. I am suggesting something similar to Dan's third option below (Tue Nov 29 2011 "the nsw story”, Dan Gohman), when hoisting an instruction with ‘nsw’ it looses the ‘nsw’ attribute, but without saying “add-nsw is a fully side-effecting instruction”. This option was back then seen by

Preface: This paper shows that "poison" was never actually necessary in the first place. “Poison"s existence is based on incorrect assumptions that are being explored for the first time. I have been re-reading Dan Gohman's original post "the nsw story" [1] and have come to the conclusion that Dan got it wrong in some respects. He came up with "no signed

Chandler, Please give some citations, I’ve search the llvm-dev archives and didn't find any. Peter Lawrence. > On Jun 28, 2017, at 12:01 PM, Chandler Carruth <chandlerc at gmail.com> wrote: > > On Wed, Jun 28, 2017 at 9:39 AM Peter Lawrence <peterl95124 at sbcglobal.net <mailto:peterl95124 at sbcglobal.net>> wrote: > > Preface: This paper

On 06/28/2017 02:18 PM, Chandler Carruth wrote: > On Wed, Jun 28, 2017 at 12:09 PM Peter Lawrence > <peterl95124 at sbcglobal.net <mailto:peterl95124 at sbcglobal.net>> wrote: > > Chandler, > Please give some citations, I’ve search the > llvm-dev archives and didn't find any. > > > They are all in the discussions from Nuno,

[This mail could be an answer to the other responses as well, as they basically are the same.] Ah, I think I understand now what poison is for. Adds are defined to not have side-effects, so the dependence rule is needed so the optimizer is allowed to exploit undefined behavior. Is this correct? I forgot to mention in my original mail that our trapping arithmetic operations are fully

On Nov 30, 2011, at 12:21 PM, Paul Robinson wrote: > Part of the confusion seems to come from overloading "undefined." > The VAX architecture spec nicely dealt with the distinction between > unspecified results and unspecified behavior by consistently using > distinct terms: _unpredictable_ results, and _undefined_ behavior. > An operation producing an unpredictable

Hi, In our backend, we currently emit add operations that trap on overflow if the IR operation has the nsw flag set. Is this allowed? According to the documentation about poison values, overflowing a nsw add is undefined behavior. However I didn't find a formal definition of undefined behavior in LLVM. Judging from previous discussions on the mailing list, there seems to be a vague

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 &

(If this thread is becoming tiresome, let me know. This newbie is trying to understand some of what's going on; clearly you've thought about it way more than I have, and I can understand if you want to stop thinking about it!) On Mon, Dec 5, 2011 at 2:22 PM, Dan Gohman <gohman at apple.com> wrote: > On Dec 5, 2011, at 11:55 AM, Paul Robinson wrote: > > > > On Thu,

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 >

Hi Peter, On Thu, Jun 8, 2017 at 9:41 AM, Peter Lawrence <peterl95124 at sbcglobal.net> wrote: > >> On Jun 7, 2017, at 2:23 PM, Nuno Lopes <nunoplopes at sapo.pt> wrote: >> >> Since most add/sub operations compiled from C have the nsw attribute, we cannot simply restrict movement of these instructions. > > Nuno, > I’m not saying the operations

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

> Then why does the Release Note say > " the operation is guaranteed to not overflow". It means that the person who wrote the IR has guaranteed that there's no overflow (by some means) so LLVM can assume it during optimisation. This guarantee might come from doing explicit checks before executing the add/sub; or perhaps from performing the operation after a sext so that the

On Dec 6, 2011, at 10:07 AM, Paul Robinson wrote: > On Tue, Dec 6, 2011 at 9:06 AM, David A. Greene <greened at obbligato.org> wrote: > Dan Gohman <gohman at apple.com> writes: > > > For example, suppose we want to convert the && to &, and the ?: to a > > select, in this code: > > > > if (a && (b ? (c + d) : e)) { > > >

On Dec 5, 2011, at 4:44 PM, Paul Robinson wrote: > (If this thread is becoming tiresome, let me know. This newbie is trying to > understand some of what's going on; clearly you've thought about it way more > than I have, and I can understand if you want to stop thinking about it!) > > On Mon, Dec 5, 2011 at 2:22 PM, Dan Gohman <gohman at apple.com> wrote: > On Dec

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

*** Summary I'd like to propose (and implement) functionality in LLVM to determine when a poison value from an instruction is guaranteed to produce undefined behavior. I want to use that to improve handling of nsw, inbounds etc. flags in scalar evolution and LSR. I imagine that there would be other uses for it. I'd like feedback on this idea before I proceed with it. *** Details Poison

Since most add/sub operations compiled from C have the nsw attribute, we cannot simply restrict movement of these instructions. Sure, we could drop nsw when moving these instructions, but there are still many other problems left. Please read more about the topic here: https://blog.regehr.org/archives/1496 For example, doing loop unswitching, followed by inline (just to illustrate that the

On 05/26/2017 03:02 PM, Matthias Braun wrote: > >> Regarding SDAG, and given that poison is already there, we would need >> to adopt a similar solution to the IR. Maybe right now we can get >> away with it because nsw is not exploited significantly (as you say). >> Just because there’s no explicit poison in SDAG, just having nsw is >> sufficient to cause