search for: instcombineaddsub

Sorry, the old title didn't make sense. > Hi, > > I have doubts on the following transformation in InstCombineAddSub.cpp. Is > it always safe to preserve NSW/NUW in this case? > > // If this is a 'B = x-(-A)', change to B = x+A. This preserves NSW/NUW. if (Value <https://cs.corp.google.com/#piper///depot/google3/third_party/llvm/llvm/include/llvm/IR/Value.h&ct=xref_jump_to_def&cl=G...

...tdio.h> > #include <limits.h> > > int foo(int x) > { > return -(x/INT_MIN); > } > > int main (void) > { > printf ("%d\n", foo(INT_MIN)); > } This will print -1 or 1, depending on the optimization level. This appears to be the relevant code: InstCombineAddSub.cpp:1556 > // 0 - (X sdiv C) -> (X sdiv -C) > if (match(Op1, m_SDiv(m_Value(X), m_Constant(C))) && > match(Op0, m_Zero())) > return BinaryOperator::CreateSDiv(X, ConstantExpr::getNeg(C)); - David Menendez

...T: sitofp CHECK-NOT: fadd (Those last two are to confirm you removed the other sitofp and the floating-point add) > + %a = sitofp i32 %p to double > + %b = sitofp i32 %q to double > + %result = fadd double %a, %b > + ret double %result > +} > Index: lib/Transforms/InstCombine/InstCombineAddSub.cpp > =================================================================== > --- lib/Transforms/InstCombine/InstCombineAddSub.cpp (revision 127153) > +++ lib/Transforms/InstCombine/InstCombineAddSub.cpp (working copy) > @@ -57,6 +57,30 @@ > } > > > +static bool RippleBucketE...

Hi! I've attached a patch which takes care of the issues mentioned (and adds two tests). -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name: ripple-bucket.diff Type: text/x-diff Size: 3318 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110308/0814e3e8/attachment.diff>

It seems some optimization pass converts some address computation add's into or's when it knows it's allowed due correct alignment. How do I turn this off keep the address calculations as adds?

...DAG graph later gets converted into MachineInstrs after > scheduling. > then it seems this is done: instCombine (on llvm ir) llvm ir -> selection dag lower combine legalize combine ... I wonder if there is duplicate code in instCombine (on llvm ir, e.g. llvm/lib/Transforms/InstCombine/InstCombineAddSub.cpp) and combine on selection dag, and worst of all I can't use lower since I write llvm ir into highlevel code (like CBackend) and therefore have to implement my own lower. Or do you a better idea for this? -Jochen

...;> >> > > then it seems this is done: > instCombine (on llvm ir) > llvm ir -> selection dag > lower > combine > legalize > combine > ... > > I wonder if there is duplicate code in instCombine (on llvm ir, e.g. > llvm/lib/Transforms/InstCombine/InstCombineAddSub.cpp) > and combine on selection dag, and worst of all I can't use > lower since I write llvm ir into highlevel code (like CBackend) > and therefore have to implement my own lower. Or do you > a better idea for this? > > -Jochen The same passes would be beneficial for my PTX ba...

...the patch for review. Comments inline. For those of you following at home, this code is in InstCombiner::WillNotOverflowSignedAdd(), and the first line of the initial comment is: // If one of the operands only has one non-zero bit, and if the other operand > --- lib/Transforms/InstCombine/InstCombineAddSub.cpp (revision 126747) > +++ lib/Transforms/InstCombine/InstCombineAddSub.cpp (working copy) > @@ -77,9 +77,55 @@ > // has a known-zero bit in a more significant place than it (not including the > // sign bit) the ripple may go up to and fill the zero, but won't change the >...

Hi all! I've been tinkering with LLVM's code-base for a few days, hoping to start on one of the ideas mentioned in the "Open Projects" page (I was told 'Improving the current system'/'Miscellaneous Improvements'/5 would be a good start). While I was at it, I also took a stab at finishing up one of the TODOs. I've attached the patch for review. --

Hi As I understand live variable analysis will set the def/kill properties of operands. In that case, is it still needed to set the kill flags when possible during lowering? thanks dz

On 2010-09-03 13:19, Jochen Wilhelmy wrote: > >>> Hi! >>> >>> The following thoughts about the llvm architecture I'd like to share >>> with you >>> (from the perspective of a user): >>> >>> - If a backend has no vector support, then I wonder why there is no >>> de-vectorization >>> pass that operates on

>> Hi! >> >> The following thoughts about the llvm architecture I'd like to share >> with you >> (from the perspective of a user): >> >> - If a backend has no vector support, then I wonder why there is no >> de-vectorization >> pass that operates on indermediate llvm-ir. I would think that if you >> use such a target >> then

...ry libLLVMipa.a make[3]: Leaving directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/lib/Analysis/IPA' make[2]: Leaving directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/lib/Analysis' make[3]: Entering directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/lib/Transforms/InstCombine' llvm[3]: Compiling InstCombineAddSub.cpp for Release+Asserts build llvm[3]: Compiling LoopRerollPass.cpp for Release+Asserts build llvm[3]: Compiling X86SelectionDAGInfo.cpp for Release+Asserts build llvm[3]: Compiling DwarfCFIException.cpp for Release+Asserts build llvm[3]: Compiling InstCombineAndOrXor.cpp for Release+Asserts build...