search for: instcombinemuldivrem

The LangRef says this for left shifts: "If the nsw keyword is present, then the shift produces a poison value if it shifts out any bits that disagree with the resultant sign bit." ... (1) followed by "As such, NUW/NSW have the same semantics as they would if the shift were expressed as a mul instruction with the same nsw/nuw bits in (mul %op1, (shl 1, %op2))." ... (2) But

Hi, We have recently encountered incorrect code generation issues and I think it is a SCEVExpander bug exposed by a recent patch to add nuw/nsw flags when generating code for SCEVMulExpr. The test case IR looks like this- %1 = load i16, i16* %arrayidx %2 = and i16 %1, -32768 The SCEV form of %2 is this- (-32768 * (%1 /u -32768))<nuw><nsw> It has both nsw/nuw flags. The signed

Yes - this has been in InstCombine for a long time: https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/InstCombine/InstCombineMulDivRem.cpp#L268 We could say that the canonicalization should be reversed, but that probably uncovers more missing optimizations. The code size concern is legitimate. For example on x86, gcc asm is 2 bytes smaller on this example: https://godbolt.org/z/GK9FEL To improve this, we could add a generic tra...

...o handle that. > >Sam > >> On 30 Jun 2020, at 2:08 pm, Sanjay Patel via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Yes - this has been in InstCombine for a long time: >> https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/InstCombine/InstCombineMulDivRem.cpp#L268 >> >> We could say that the canonicalization should be reversed, but that probably uncovers more missing optimizations. >> >> The code size concern is legitimate. For example on x86, gcc asm is 2 bytes smaller on this example: >> https://godbolt.org/z/GK9FEL...

...C2) <nsw>) <nsw> ** C1 & C2 are constants. Current canonicalization transforms to (X*C2+C1*C2) in both scenarios (1 & 2). To me this looks like a limitation with canonicalization where its missing guarantee to not overflow property. Please confirm my understanding. <File: InstCombineMulDivRem.cpp > 168 Instruction *InstCombiner::visitMul(BinaryOperator &I) { 268 // Canonicalize (X+C1)*CI -> X*CI+C1*CI. 269 { 270 Value *X; 271 Constant *C1; 272 if (match(Op0, m_OneUse(m_Add(m_Value(X), m_Constant(C1))))) { 273 Value *Mul = Builder->Cr...

...m-revision.src/cfe/trunk/lib/CodeGen/CodeGenFunction.cpp * Commit *257496* by *spatel:* function names start with a lower case letter ; NFC o *edit*: llvm-revision.src/llvm/trunk/include/llvm/IR/IRBuilder.h o *edit*: llvm-revision.src/llvm/trunk/lib/Transforms/InstCombine/InstCombineMulDivRem.cpp o *edit*: llvm-revision.src/llvm/trunk/lib/Transforms/InstCombine/InstCombineSelect.cpp o *edit*: llvm-revision.src/llvm/trunk/lib/Transforms/Utils/LoopUtils.cpp o *edit*: llvm-revision.src/llvm/trunk/lib/Transforms/Utils/SimplifyLibCalls.cpp o *edit*:...

Hi, James, Thanks for your reply. I do not think it is always true, that "mul then add" is faster than "add then mul". For example, A small immediate can be directly encoded in the instruction, but it becomes a larger one after a multiplication, which has to be loaded from the constant pool (extra memory access). So I wonder, is it possile to prevent it, via changes

...lding Release+Asserts Archive Library libLLVMX86CodeGen.a make[4]: Entering directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/lib/Target/X86/InstPrinter' llvm[4]: Compiling X86ATTInstPrinter.cpp for Release+Asserts build llvm[3]: Compiling DwarfUnit.cpp for Release+Asserts build llvm[3]: Compiling InstCombineMulDivRem.cpp for Release+Asserts build llvm[3]: Compiling LowerExpectIntrinsic.cpp for Release+Asserts build llvm[4]: Compiling X86InstComments.cpp for Release+Asserts build llvm[3]: Compiling MemCpyOptimizer.cpp for Release+Asserts build llvm[4]: Compiling X86IntelInstPrinter.cpp for Release+Asserts build...