On Tue, Jul 6, 2010 at 8:34 PM, Chris Lattner <clattner at apple.com> wrote:> > On Jul 6, 2010, at 3:37 PM, Jianzhou Zhao wrote: > >> Which semantics is better? I guess both are fine because if we assume >> these two def's are same, then it is 0 as >> 'ConstantFoldBinaryInstruction', while if we assume they are different >> then it is equal to undef. But the second case seems to include the >> first one. If we let undef xor undef to be undef, later we can use >> this undef as 0, but also other values w.r.t contexts. Is there any >> reason that ConstantFoldBinaryInstruction uses the first assumption? > > The right answer is that undef ^ undef = undef. Folding it to 0 is a conservatively correct approximation of undef. This is done because (annoyingly) a lot of people write things like this: > > int x; > x = x^x; > > As a "clever" way of clearing out x, particularly for vectors which don't have a convenient 0 literal. This is nonsense, but common enough to try to not completely break.Does this also apply to two different variables? say int z x y; z = x ^ y; If ConstantFoldBinaryInstruction also folds x ^ y into z, should this pass (which uses ConstantFold) also initialize x and y with a same initial value? Otherwise at runtime z may not be 0.> > -Chris-- Jianzhou
On Tue, Jul 6, 2010 at 10:07 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote:> On Tue, Jul 6, 2010 at 8:34 PM, Chris Lattner <clattner at apple.com> wrote: >> >> On Jul 6, 2010, at 3:37 PM, Jianzhou Zhao wrote: >> >>> Which semantics is better? I guess both are fine because if we assume >>> these two def's are same, then it is 0 as >>> 'ConstantFoldBinaryInstruction', while if we assume they are different >>> then it is equal to undef. But the second case seems to include the >>> first one. If we let undef xor undef to be undef, later we can use >>> this undef as 0, but also other values w.r.t contexts. Is there any >>> reason that ConstantFoldBinaryInstruction uses the first assumption? >> >> The right answer is that undef ^ undef = undef. Folding it to 0 is a conservatively correct approximation of undef. This is done because (annoyingly) a lot of people write things like this: >> >> int x; >> x = x^x; >> >> As a "clever" way of clearing out x, particularly for vectors which don't have a convenient 0 literal. This is nonsense, but common enough to try to not completely break. > > Does this also apply to two different variables? say > int z x y; > z = x ^ y; > If ConstantFoldBinaryInstruction also folds x ^ y into z, should this > pass (which uses ConstantFold) also initialize x and y with a same > initial value? Otherwise at runtime z may not be 0.I guess my question is what variables can have undef values. In my understanding, only uninitialized locals and globals can be undefined, so compilers are free to assign them at runtime, if ConstantFoldBinaryInstruction ensures that x and y can only be locals and globals. But function parameters cannot be undefined, which should be arbitrary symbols, depending on concrete arguments. Is this correct?> >> >> -Chris > > > > -- > Jianzhou >-- Jianzhou
On Jul 7, 2010, at 5:47 AM, Jianzhou Zhao wrote:>> >> Does this also apply to two different variables? say >> int z x y; >> z = x ^ y; >> If ConstantFoldBinaryInstruction also folds x ^ y into z, should this >> pass (which uses ConstantFold) also initialize x and y with a same >> initial value? Otherwise at runtime z may not be 0. > > I guess my question is what variables can have undef values. In my > understanding, only uninitialized locals and globals can be undefined, > so compilers are free to assign them at runtime, if > ConstantFoldBinaryInstruction ensures that x and y can only be locals > and globals. But function parameters cannot be undefined, which should > be arbitrary symbols, depending on concrete arguments. Is this > correct?I don't really understand your question here. Are you asking about C or LLVM IR, or something else? -Chris