search for: nofold

Hi all, while I was playing a little bit with IRBuilder I ended up with something like this when included NoFolder.h /work/llvm/include/llvm/User.h: In member function ‘llvm::Value* llvm::NoFolder::CreateExtractElement(llvm::Constant*, llvm::Constant*) const’: /work/llvm/include/llvm/User.h:48: error: ‘static void* llvm::User::operator new(size_t)’ is private /work/llvm/include/llvm/Support/NoFolder.h:177: e...

Hi, Just to report that 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&...

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) that's probably best... :( > > (It's also missing most of the casting operations, by the way) I just submitted a patch to fix all of thos...

IRBuilder is a templated class, and one of the template arguments is the constant folder to use. By default it uses the ConstantFolder class which does target-independant constant folding. If you want to disable constant folding you can specify the NoFolder class instead, i.e. declare the builder as follows: IRBuilder<true, llvm::NoFolder> builder(body) On 26 Nov 2013, at 19:23, Daniel Albuschat <d.albuschat at gmail.com> wrote: > Hello, > > using the LLVM API, I've build one very simple function that adds two > Const...

Hello, using the LLVM API, I've build one very simple function that adds two ConstantInts and returns the result. I noticed that, when I emit IR code, it is optimized to a simple "ret i16 42" when I add 40 and 2. I'd like to see the operations that are necessary to compute the result, though. Can I somehow disable this optimization in the pass, leading to more verbose IR code?

I want to create an add instruction that takes two constant operands at the LLVM IR level. I use the IRBuilder class, but nothing happens. Here is part of the runOnFunction() method of my function pass: ... LLVMContext &Context = F.getContext(); IRBuilder<> builder(&Instruction); Value *Lef = ConstantInt::get(Type::getInt32Ty(Context), 4); Value *Rig =

...is again very simple: ... bool runOnFunction(Function &F) override { vector<Instruction *> dels; dels.clear(); for (inst_iterator It = inst_begin(&F), Ie = inst_end(&F); It != Ie;) { Instruction *I = &*(It++); if (auto* op = dyn_cast<BinaryOperator>(I)) { IRBuilder<NoFolder> builder(op); Value* lhs = op->getOperand(0); Value* rhs = op->getOperand(1); Value* mul = builder.CreateMul(lhs, rhs); for (auto& U : op->uses()) { User* user = U.getUser(); user->setOperand(U.getOperandNo(), mul); } //I->eraseFromParent(); dels.push_back(I); } } for...

...on(Function &F) override { > > vector<Instruction *> dels; > dels.clear(); > > for (inst_iterator It = inst_begin(&F), Ie = inst_end(&F); It != Ie;) { > Instruction *I = &*(It++); > > if (auto* op = dyn_cast<BinaryOperator>(I)) { > IRBuilder<NoFolder> builder(op); > > Value* lhs = op->getOperand(0); > Value* rhs = op->getOperand(1); > Value* mul = builder.CreateMul(lhs, rhs); > > for (auto& U : op->uses()) { > User* user = U.getUser(); > user->setOperand(U.getOperandNo(), mul); > } > //I-&g...

Are you calling llvm_shutdown() at the end of your program? You should. valgrind reports "possible" leaks when it finds a pointer pointing inside a memory block (as opposed to at the first byte), and LLVM uses those a lot. llvm_shutdown() will free a lot of that memory, including the LLVMContext, which should remove any false leaks you might be seeing. On the other hand, the

Hi edA-qa mort-ora-y, On 02/11/12 10:20, edA-qa mort-ora-y wrote: > I'm having trouble figuring out what the error "Instruction does not > dominate all uses!" means. I'm trying to construct a call to a function > with two parameters. The printed IR, with error, looks like this: > > define i32 @add(i32, i32) { > EntryBlock: > %2 = add i32 %0, %1 >

I'm having trouble figuring out what the error "Instruction does not dominate all uses!" means. I'm trying to construct a call to a function with two parameters. The printed IR, with error, looks like this: define i32 @add(i32, i32) { EntryBlock: %2 = add i32 %0, %1 ret i32 %2 } define i32 @eval_expr() { EntryBlock: ret i32 <badref> } Instruction does not dominate

Thanks Bjorn! But The problem is still there. On Wed, Aug 8, 2018 at 2:04 AM, Björn Pettersson A < bjorn.a.pettersson at ericsson.com> wrote: > It looks quite dangerous to erase the instruction I inside the loop when > iterating over all instructions in the function. > I guess it depends on how the range based iterator is implemented if that > works or not. > > I think

...unk/test/CodeGen/X86/shift-bmi2.ll >> llvm/trunk/test/CodeGen/X86/sink-hoist.ll >> llvm/trunk/test/CodeGen/X86/sse2.ll >> llvm/trunk/test/CodeGen/X86/store-narrow.ll >> llvm/trunk/test/CodeGen/X86/tailcall-largecode.ll >> llvm/trunk/test/CodeGen/X86/test-nofold.ll >> llvm/trunk/test/CodeGen/X86/trunc-to-bool.ll >> llvm/trunk/test/CodeGen/X86/v-binop-widen.ll >> llvm/trunk/test/CodeGen/X86/v-binop-widen2.ll >> llvm/trunk/test/CodeGen/X86/vec_shuffle-27.ll >> llvm/trunk/test/CodeGen/X86/vec_shuffle-39.ll >>...

...nclude/llvm/Support/MathExtras.h -- Installing: /usr/local/llvm-2.8/include/llvm/Support/MemoryBuffer.h -- Installing: /usr/local/llvm-2.8/include/llvm/Support/MemoryObject.h -- Installing: /usr/local/llvm-2.8/include/llvm/Support/MutexGuard.h -- Installing: /usr/local/llvm-2.8/include/llvm/Support/NoFolder.h -- Installing: /usr/local/llvm-2.8/include/llvm/Support/OutputBuffer.h -- Installing: /usr/local/llvm-2.8/include/llvm/Support/PassNameParser.h -- Installing: /usr/local/llvm-2.8/include/llvm/Support/PatternMatch.h -- Installing: /usr/local/llvm-2.8/include/llvm/Support/PluginLoader.h -- Instal...

On Thu, Sep 30, 2010 at 3:08 PM, Samuel Williams <space.ship.traveller at gmail.com> wrote: > Hi, > > I might just be doing something stupid, but when I do > > $ cmake -DCMAKE_INSTALL_PREFIX=/usr/local/llvm-2.8 -DCMAKE_BUILD_TYPE=Release .. > $ sudo make install > > I don't get the expected headers in >        /usr/local/llvm-2.8/include/llvm > > It is

Hi, I might just be doing something stupid, but when I do $ cmake -DCMAKE_INSTALL_PREFIX=/usr/local/llvm-2.8 -DCMAKE_BUILD_TYPE=Release .. $ sudo make install I don't get the expected headers in /usr/local/llvm-2.8/include/llvm It is simply an empty directory. What am I doing wrong? This is on Mac OS X, CMake 2.8+ Kind regards, Samuel

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==