search for: createfneg

...when I tried to compile some code with a NoFolder given as template arg to my IRBuilder, the compiler complained with: In file included from lang_3-llvm.cxx:33: /usr/lib/llvm-2.8/include/llvm/Support/IRBuilder.h: In member function ‘llvm::Value* llvm::IRBuilder<preserveNames, T, Inserter>::CreateFNeg (llvm::Value*, const llvm::Twine&) [with bool preserveNames = true, T = llvm::NoFolder, Inserter = llvm::IRBuilderDefaultInserter<true>]’: ... I just added Value *CreateFNeg(Constant *C) const { return BinaryOperator::CreateFNeg(C); } amongst the unary operators of NoFolder...

Hello, Thanks for the patch. I applied it on trunk. I suspect it's too late for 2.6 though. Dan On Sep 28, 2009, at 1:38 PM, KS Sreeram wrote: > Hi folks, > > The llvm c-api contains LLVMBuildNeg but not LLVMBuildFNeg. I've > attached a simple patch which adds LLVMBuildFNeg. > > I know it's a little late, but it'll be great if this can be added > for

On Wed, Nov 17, 2010 at 9:26 PM, BernardH <gmane.comp.compilers.llvm.devel at bernard-hugueney.org> wrote: > Should I consider NoFolder unsupported ? Seeing as it's completely broken (it doesn't insert the created instructions into the relevant basic block) that's probably best... :( (It's also missing most of the casting operations, by the way)

On Wed, Nov 17, 2010 at 9:37 PM, Frits van Bommel <fvbommel at gmail.com> wrote: > On Wed, Nov 17, 2010 at 9:26 PM, BernardH > <gmane.comp.compilers.llvm.devel at bernard-hugueney.org> wrote: >> Should I consider NoFolder unsupported ? > > Seeing as it's completely broken (it doesn't insert the created > instructions into the relevant basic block)

Hi folks, The llvm c-api contains LLVMBuildNeg but not LLVMBuildFNeg. I've attached a simple patch which adds LLVMBuildFNeg. I know it's a little late, but it'll be great if this can be added for the 2.6 release. I'm asking because I'd like to add support for FNeg in llvm-py too, and it'll be hard to do that if llvm 2.6 doesn't have it. Regards KS Sreeram

On Tue, Sep 25, 2018 at 1:39 PM Sanjay Patel <spatel at rotateright.com> wrote: > I have 1 concern about adding an explicit fneg op to IR: > > Currently, fneg qualifies as a binop in IR (since there's no other way to > represent it), and we have IR transforms that are based on matching that > pattern (m_BinOp). With a proper unary fneg instruction, those transforms >

...on::FNeg). Any transform that currently uses m_FNeg(...) would >> fail to build without an update. >> > > We don't want to get rid of the m_FNeg calls. Those are safe because > they're providing an abstraction to the callers. Ie, anywhere we use > m_FNeg() or Builder.CreateFNeg() should Just Work regardless of how we > implement the underlying fneg operation. (We have to fix those function > themselves of course to deal with the new opcode.) It's the code that > doesn't use those abstractions that has the potential to regress. > > Here's an exam...