search for: visitfmul

...f thing for real in the mid-level optimizer, some thoughts are here: > http://nondot.org/sabre/LLVMNotes/FloatingPointChanges.txt > Thanks, now it works. I inserted if (Op1F->isNullValue()) return ReplaceInstUsesWith(I, Op1C); // X * 0 == 0 into llvm::InstCombiner::visitFMul Why not at first create a compile time option for this so that the code is already available for special purposes? -Jochen

...But I think part of the vector-predication proposal includes some generic matchers for the different intrinsic, which should be relatively straight-forward to update as well. > > > Yes, the IR passes are where I see complex types win. For example, > pretty much all of InstCombine's visitFMul(...) transformations should > not depend on type.*** So there's no need to duplicate all that code > for @llvm.complex.multiply. > > It's true that teaching the pattern matcher to recognize intrinsics > gets us a long way. But we'd also need to update IR passes in places...

...asier to deal with. But I think part of the vector-predication proposal includes some generic matchers for the different intrinsic, which should be relatively straight-forward to update as well. Yes, the IR passes are where I see complex types win. For example, pretty much all of InstCombine's visitFMul(...) transformations should not depend on type.*** So there's no need to duplicate all that code for @llvm.complex.multiply. It's true that teaching the pattern matcher to recognize intrinsics gets us a long way. But we'd also need to update IR passes in places where the Opcode is expl...

> You should check out the -enable-finite-only-fp-math and -enable-unsafe-fp-math options. Good hint, but llvm::UnsafeFPMath = true; llvm::FiniteOnlyFPMathOption = true; at the beginning of my code does not help. I found llvm::Reassociate::OptimizeExpression in llvm\lib\Transforms\Scalar\Reassociate.cpp which looks like it does X * 0 = 0 for int, but it does not get called for

On Mar 3, 2010, at 10:23 AM, Jochen Wilhelmy wrote: > >> You should check out the -enable-finite-only-fp-math and -enable-unsafe-fp-math options. > > Good hint, but > > llvm::UnsafeFPMath = true; > llvm::FiniteOnlyFPMathOption = true; > > at the beginning of my code does not help. > I found llvm::Reassociate::OptimizeExpression in >

...mizer, some thoughts are here: >> http://nondot.org/sabre/LLVMNotes/FloatingPointChanges.txt >> > > Thanks, now it works. I inserted > > if (Op1F->isNullValue()) > return ReplaceInstUsesWith(I, Op1C); // X * 0 == 0 > > into llvm::InstCombiner::visitFMul > > Why not at first create a compile time option for this so that the > code is already available for special purposes? I'm not sure how that would work, but it most likely wouldn't fit with the design of llvm. If this is important, I'd rather fix the representational issue...

...ith. But I think part of the vector-predication proposal includes some generic matchers for the different intrinsic, which should be relatively straight-forward to update as well. > > Yes, the IR passes are where I see complex types win. For example, > pretty much all of InstCombine's visitFMul(...) transformations should > not depend on type.*** So there's no need to duplicate all that code > for @llvm.complex.multiply. > > It's true that teaching the pattern matcher to recognize intrinsics > gets us a long way. But we'd also need to update IR passes in places...

On Thu, Nov 12, 2020 at 12:03 PM Florian Hahn via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > There’s growing interest among our users to make better use of dedicated hardware instructions for complex math and I would like to re-start the discussion on the topic. Given that this original thread was started a while ago apologies if I missed anything already discussed