[LLVMdev] RFC: Proposal to Remove Poison

Hal Finkel hfinkel at anl.gov
Sun Feb 8 13:19:37 PST 2015


----- 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.

(*) 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



More information about the llvm-dev mailing list