[LLVMdev] RFC: Proposal to Remove Poison

David Majnemer david.majnemer at gmail.com
Sun Feb 8 14:37:16 PST 2015


On Sun, Feb 8, 2015 at 1:19 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> ----- Original Message -----
> > From: "Reid Kleckner" <rnk at google.com>
> > To: "Hal Finkel" <hfinkel at anl.gov>
> > Cc: "David Majnemer" <david.majnemer at gmail.com>, "Nuno Lopes" <
> nuno.lopes at ist.utl.pt>, "John Regehr"
> > <regehr at cs.utah.edu>, "LLVM Developers Mailing List" <
> llvmdev at cs.uiuc.edu>
> > Sent: Sunday, February 8, 2015 2:20:49 PM
> > Subject: Re: [LLVMdev] RFC: Proposal to Remove Poison
> >
> >
> > On Sun, Feb 8, 2015 at 10:02 AM, Hal Finkel < hfinkel at anl.gov >
> > wrote:
> >
> > When you say, "we'd like to", I'm assuming your justification for
> > this is so that we can model poison using these undef semantics. Is
> > that correct?
> >
> > Yes, but I also think 'icmp sgt i32 undef, %a -> i1 undef' is a
> > pretty reasonable transform by itself. Well-defined programs should
> > never observe the result of the compare.
>
> I'm somewhat concerned that this is unsound. For example, imagine I have
> the following:
>
> void foo(int &a, int n) {
>   int c = INT_MAX, r = 0;
>   for (int i = 0; i < n; ++i, --c) {
>     if (a > c)
>       r += a;
>     else
>       a = bar();
>   }
>
>   return r;
> }
>
> called like this:
>
>   int q;
>   return foo(&q, 5);
>
> However, we now have a situation where:
>   1) in the first iteration the value loaded from &a is uninitialized
>   2) after inlining the loop will likely be fully unrolled, and so the
> initial value loaded will be replaced by an undef
>   3) it is the fact that, in that first iteration, (a > c, where c ==
> INT_MAX) is always false that protects the undefined value from propagating
> further
>
> I'm also assuming that it is desirable that 'int c = INT_MAX' should have
> the same behavior as 'int c = opaque_func_that_returns_INT_MAX()'.
>
> To be clear, I'm not entirely convinced that this is a well-defined C++
> program (*), however, I believe it is well defined under our current
> semantics at the IR level. What is being proposed would change that.
>

I don't think that program is reasonable.  I also don't think my proposal
changes the facts on the ground.

consider:
bool f(int x, int y, bool c) {
  int add;
  if (c)
    add = x + y;
  return add > x;
}

Are we permitted to optimize this program to:
bool f(int x, int y, bool c) {
  return y > 0;
}

?

We do so today.


> (*) 8.5p12 says only, "If an indeterminate value is produced by an
> evaluation, the behavior is undefined except in the following cases..."
> [there are some special cases involving values of character type]. There is
> also a footnote on 3.9.1p6, discussing bool, that says, "Using a bool value
> in ways described by this International Standard as `undefined,` such as by
> examining the value of an uninitialized automatic object, might cause it to
> behave as if it is neither true nor false." But it is not really clear to
> me whether (c > INT_MAX) is an evaluation having an indeterminate value
> (except via some circular reasoning).
>
>  -Hal
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150208/6d4a3199/attachment.html>


More information about the llvm-dev mailing list