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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150208/aea9ddb1/attachment.html>
----- 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
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>
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. >OK, this isn't a well formed C program: C11 6.7.9p10: If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate. C11's annex on undefined behavior, J has: The value of an object with automatic storage duration is used while it is indeterminate.> > (*) 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/95d8c436/attachment.html>