similar to: [RFC] IRBuilder polymorphism: Templates/virtual

Hi, I have problem with IRBuilderBase::InsertPointGuard class that simply does not work in the release build of my project. The class does not restore the IRBuilder's insert point correctly when NDEBUG macro is set. It happens on OSX system only, trunk version of the LLVM built with brew. I suspect it is the ABI problem. InsertPointGuard uses AssertingVT for debug builds. LLDB gets confused

Sorry, these IRBuilder methods are really in IRBuilderBase. Garrison On Jul 11, 2011, at 11:54, Garrison Venn wrote: > Are the get type methods for IRBuilder, such as const IntegerType *getInt32Ty(), going to have > their return type const qualifiers removed? Doing so would match the semi equivalent static > methods of Type, such as static IntegerType *getInt32Ty(LLVMContext &C).

Hi, I am trying to use some LLVM API in my C++ code, and I end up getting linker errors. I am working on Apple MacOSX Lion. Using g++ for the compile. It is the CreateGlobalStringPtr which is throwing the error. This is LLVM 3.0. Here's the codeI am trying to use some LLVM API in my C++ code, and I end up getting linker errors. I am working on Apple MacOSX Lion. Using g++ for the compile. It

Attached is a patch for the non ExceptionDemo demos which gets rid of the old const qualifier usage for Type. Although I recently commited the ExceptionDemo changes, I did not want to touch code that I did not "own" without other's approval. Even though trivial, I did not test this patch. Garrison -------------- next part -------------- A non-text attachment was scrubbed... Name:

Probably your g++ compiles x86_64 binary by default, but i686 dylib is supplied? Try: g++ -m32 e.cpp /Developer/Platforms/iPhoneOS.platform/Developer/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin10/4.2.1/libllvmgcc.dylib - D. 2012/1/22 Arpan Sen <arpansen at gmail.com>: > Hi, > > I am trying to use some LLVM API in my C++ code, and I end up getting linker > errors. I am

Hi Alexandre, Sorry I missed this -- I was on vacation when you sent this. SCEVExpander already has an IRBuilder in it but AFAICT it isn't exposed as a public interface. I'd be fine if you wanted to expose a public `GetIRBuilder()` accessor that let a SCEVExpander client use the same IRBuilder as SCEVExpander. -- Sanjoy On Fri, Apr 6, 2018 at 10:55 AM, Alexandre Isoard via llvm-dev

Hello, I use SCEVExpander and IRBuilder to generate some code and I frequently end-up breaking dominance because the SCEVExpander insertion point and the IRBuilder insertion point do not advance in synchrony. Ideally, I could build a SCEVExpander based on an existing IRBuilder (so that they move each other). Or even better, SCEVExpander inherit from IRBuilder and basically extend it with SCEV

Hey, Alternatively, expose a SCEVExpander::getInsertPoint? This would proxy the underlying IRbuilder, with no real state sharing, other than the current insert point. This will be less ugly than recieving the expanded SCEV value, casting to an instruction, and feeding this to the IRBuilder. Cheers, siddharth On Thu 3 May, 2018, 15:36 Philip Pfaffe via llvm-dev, < llvm-dev at

Hi Alex, Sanjoy, exposing the internal IRBuilder to users of SCEVExpander violates information hiding, and encourages the tight coupling that makes code bases such as Polly so hard to maintain. SCEVExpander::expandCodeFor returns a Value that (if it's an instruction) can be used to update the insert point of the client's IRBuilder. Is that not enough? No hidden state, no hidden state

I've got a ticket open where I would very much like some input from maintainers of other languages that rely on llvm and use the IRBuilder. See: Teach the IRBuilder about constrained fadd and friends: https://reviews.llvm.org/D53157 I'm adding support to functions like CreateFAdd() the ability to optionally emit the constrained math intrinsics required to support strict floating point

Hi, I need to control IRBuilder(or manage IR building with other means) very strictly. The problem is in the realm of ConstInt/GlobalVariable handling, more precisely: LLVM converts llvm::ConstantInt values to GlobalVariable addresses ad-hoc if I store a constant in a GlobalVariable, and it appears to me, that I can do nothing about it. Consider the following, shortened code: ... 0x18: r2 =

Are the get type methods for IRBuilder, such as const IntegerType *getInt32Ty(), going to have their return type const qualifiers removed? Doing so would match the semi equivalent static methods of Type, such as static IntegerType *getInt32Ty(LLVMContext &C). Thanks in advance Garrison On Jul 9, 2011, at 3:35, Chris Lattner wrote: > FYI, the type-system-rewrite branch is landing

Hi all, How do I generate the movq2dq SSE2 instruction using the IRBuilder? There is no zext from 64-bit to 128-bit (corresponding to MMX to XMM register transfer) as far as I can tell. So I've tried inserting an i64 into a v2i64, which generates valid code but rather a number of stores and loads on the stack instead of a single movq2dq. Looking though the code, I found a pattern for

Hi LLVM, IRBuilder can fold constants (that behaviour can be controlled by Folder type). What do you think about optionally allow IRBuilder to eliminate no-op instructions like `add %a, 0` or `memcpy(%a, %b, 0)`? - Paweł -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150423/4f99a092/attachment.html>

I have a variadic intrinsic that is defined as something like this: def int_foobar : Intrinsic<[llvm_anyint_ty], [llvm_vararg_ty], [IntrNoMem, IntrSpeculatable]>; When I construct a call to the above intrinsic with IRBuilder::CreateIntrinsic, it mangles the intrinsic name with the return type (i64) and the actual argument

Hi Geoff, Nothing in that backtrace leaps out at me. Based on the stack trace and description my first guess would be a clang misconfiguration rather than a JIT bug. How is that clang invocation being made? Is it from inside a callback from ORC, or is it before you add your module to the JIT? -- Lang. On Mon, Aug 3, 2020 at 5:41 AM Geoff Levner <glevner at gmail.com> wrote: > Here,

Dear Developers, I would like get detailed info if verification of the intermediate representation fails. Currently I am using IRBuilder to create a module, and I encountered an error, which I cannot trace back to the IRBuilder related call, which caused the error: "Instruction does not dominate all uses! %14 = load i32, i32* @r6 <https://github.com/r6> %11 = trunc i32 %14 to i8 LLVM

I guess currently we do not have these arithmetic with overflow variants in IRBuilder . So CreateCall is the only way to do it. Is it a good idea to add them into the IRBuilder? even thought they are in turn implemented with CreateCall only? - sanjiv -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi Everyone, I'm quite new to LLVM and I want to update value of global variable in LLVM IR. I created new global variable in ModulePass: bool runOnModule(llvm::Module &M) { IRBuilder<> Builder(M.getContext()); Instruction *I = &*inst_begin(M.getFunction("main")); Builder.SetInsertPoint(I); M.getOrInsertGlobal("globalKey",

I don't think it's the same problem as you described. By printing I meant calling printf function and passing my global variable as one of the arguments. My code: Instruction* InstructionVisitor::incrementGlobalKey(Instruction* I) { IRBuilder<> Builder(I->getContext()); Builder.SetInsertPoint(I->getNextNode()); GlobalVariable* key =