similar to: [LLVMdev] ConstantFold 'undef xor undef'

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

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

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

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

On Wed, Jul 7, 2010 at 11:38 AM, Chris Lattner <clattner at apple.com> wrote: > > 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

Hi again, It's partially done. My concern is that it won't be accepted as is because of adding the flag parameter in a lot of places. I'd like to show what it looks like (here, not on llvm-commit yet), maybe someone could suggest a better way. There are two sources of the flag: field of TargetOptions and function attribute. I had to add the later one for InstCombine pass. Still

Hi Jeffrey, Listed below the Full valgrind report (using latest revision r99309) The program creates many thousands of instructions and values as you can see from the report below ==20504== Memcheck, a memory error detector ==20504== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==20504== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright info ==20504==

Hi Sanjay, Thanks, I saw this flag and it's definitely should be considered, but it appeared to me to be static characteristic of target platform. I'm not sure how appropriate it would be to change its value from a front-end. It says "Has", while optional flag would rather say "Uses" meaning that implementation cares about floating point exceptions. Regards, Sergey

On Sun, Jul 31, 2011 at 3:04 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: > The current memory model section ends with the following discussions: > > "Note that in cases where none of the atomic intrinsics are used, this > model places only one restriction on IR transformations on top of what > is required for single-threaded execution: introducing a store to a

On Sun, Jul 31, 2011 at 7:11 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Sun, Jul 31, 2011 at 3:04 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: >> The current memory model section ends with the following discussions: >> >> "Note that in cases where none of the atomic intrinsics are used, this >> model places only one restriction on

I am confused by this bit of code in instcombine: 09789 if (GetElementPtrInst *GEPI = dyn_cast<GetElementPtrInst>(Op)) { 09790 const Value *GEPI0 = GEPI->getOperand(0); 09791 // TODO: Consider a target hook for valid address spaces for this xform. 09792 if (isa<ConstantPointerNull>(GEPI0) && 09793

The current memory model section ends with the following discussions: "Note that in cases where none of the atomic intrinsics are used, this model places only one restriction on IR transformations on top of what is required for single-threaded execution: introducing a store to a byte which might not otherwise be stored to can introduce undefined behavior.... " Why is introducing

On Fri, 4 Apr 2008, David Greene wrote: > I am confused by this bit of code in instcombine: > > 09789 if (GetElementPtrInst *GEPI = dyn_cast<GetElementPtrInst>(Op)) { > 09790 const Value *GEPI0 = GEPI->getOperand(0); > 09791 // TODO: Consider a target hook for valid address spaces for this > xform. > 09792 if (isa<ConstantPointerNull>(GEPI0)

On Mon, Aug 22, 2011 at 5:29 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: > On Mon, Aug 22, 2011 at 7:27 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: >> On Mon, Aug 22, 2011 at 3:49 PM, Eli Friedman <eli.friedman at gmail.com> wrote: >>> On Mon, Aug 22, 2011 at 3:40 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: >>>> On

> On Dec 8, 2014, at 5:12 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Partially answering my own question, in general these are not > equivalent because LLVM allows for pointers in different address > spaces to have different sizes. However, are they equivalent if > pointers in addrspace(1) have the same size as pointers in > addrspace(0)? > >

Hi I get huge memory leaks using LLVM IRBuilder (trunk version) Basically I recreate a function over and over again, and pretty sure that my code doesn't cause the leak while(true) { Function *fn = module->getFunction(name); if (fn) fn->eraseFromParent(); fn = cast<Function>(module->getOrInsertFunction(name, fnType)); fillFunction(fn); //Fill function with

Following simple program gives different answers when compiling with GCC (4.8.4) and ToT Clang: $ cat builtin_fmodf_bugpoint.cpp #include <cstdio> int main(int argc, char** argv) { const float a = 1.0f; const float b = 0.1f; printf("%f mod %f = %f\n", a, b, __builtin_fmodf(a, b)); return 0; } $ g++ -o builtin_fmodf_bugpoint_gcc builtin_fmodf_bugpoint.cpp $

Hi, On Fri, Dec 30, 2016 at 9:23 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Fri, Dec 30, 2016, 9:04 PM Sanjoy Das via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> Hi David, >> >> Looking at the original bug, it seems like a straightforward >> undef-propagation bug to me -- SCCP was folding "or undef, constant"

Hi David, Looking at the original bug, it seems like a straightforward undef-propagation bug to me -- SCCP was folding "or undef, constant" to "undef", which is wrong. Why is changing that not the fix? That is, some variant of diff --git a/lib/Transforms/Scalar/SCCP.cpp b/lib/Transforms/Scalar/SCCP.cpp index 8a6be97..45f1241 100644 --- a/lib/Transforms/Scalar/SCCP.cpp +++

On Mon, Aug 22, 2011 at 8:46 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: > On Mon, Aug 22, 2011 at 6:08 PM, Eli Friedman <eli.friedman at gmail.com> wrote: >> On Mon, Aug 22, 2011 at 2:49 PM, Santosh Nagarakatte >> <santosh.nagarakatte at gmail.com> wrote: >>> Hi all, >>> >>> I have been trying to understand the use of undef in