similar to: [RFC] Setting the current debug loc when the insertion point changes

> On Nov 6, 2017, at 2:32 PM, Adrian Prantl <aprantl at apple.com> wrote: > > >> On Nov 6, 2017, at 2:19 PM, Vedant Kumar <vsk at apple.com> wrote: >> >> Hi everybody, >> >> I'm investigating some correctness issues with debug line table information in optimized code. I've noticed something problematic in IRBuilder. Setting the

> On Nov 6, 2017, at 2:58 PM, Adrian Prantl <aprantl at apple.com> wrote: > > > >> On Nov 6, 2017, at 2:50 PM, Vedant Kumar <vsk at apple.com> wrote: >> >>> >>> On Nov 6, 2017, at 2:32 PM, Adrian Prantl <aprantl at apple.com> wrote: >>> >>> >>>> On Nov 6, 2017, at 2:19 PM, Vedant Kumar <vsk at

Hi All, I've run into what appears to be a bug in ScalarEvolution, but I'm not sure if it is instead caused by me missing an implicit assumption between LSR and SCEV. This issue is caused by the change D18001 <http://reviews.llvm.org/D18001> , which is an attempt to increase SCEV-inserted instruction re-use by picking a more canonical insertion position in the case where a new

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

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 Geoff, Thanks for the detailed reproduction instruction -- they were very helpful, and I can now see the bug. Generally, I think (2) is the better solution. It should be up to SCEVExpander to keep its state consistent. The fact that we're trying to optimize instructions as we insert them makes that trickier, but I still think that is the right invariant to have. I don't see why (2)

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

So one way might look like this: IRBuilder<> Builder(&*BB); // BB = Function::iterator OR IRBuilder<> Builder(CallInst->getParent()); Builder.SetInsertPoint(CallInst); InstructionClass *YourNewInstruction = builder.CreateInstructionClass(.....); // InstructionClass = type of instruction you are inserting -Ryan On Sat, Sep 3, 2016 at 6:04 PM, Ryan Taylor <ryta1203 at

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

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 =

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",

Hi, I'm Ryo Ota. I'm using LLVM 3.8.1. I have a quesion about inlining function in C++ API. I'd like to inline some functions in a module in the same way as `opt -inline` command. But my C++ code didn't work what I want to do. For example, by using `opt -inline` command,`main.ll` is converted into the `inlined.ll`(`opt` command worked what I want to do) [main.ll (Not inlined)]

On Sun, Sep 4, 2016 at 7:44 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Mehdi, > > Sorry, I misread his original post. > > So something like: > > XXXInsrtInfo *XII; // target instruction info > MachineBasicBlock::iterator MI = MachineBasicBlock(YourCallInst); > MachineBasicBlock *MBB = YourCallInst->getParent(); // basic block > location of

Hmmm that is a funny sequence. I know the .cfi directives are represented as pseudo-instructions, but they should not be causing us to emit .loc directives. They have no effect on the .text section so probably they should just be excluded from emitting a location, same as DBG_VALUE is excluded. Also I believe the label there is unnecessary, but that's a separate issue. Regarding "how

Hi I want to insert some functions into the llvm bitcode ir files. So I use IRBuilder and CreateCall(). But it how error : inlinable function call in a function with debug info must have a !dbg location. I don't know what DebugLoc should I give the new CallInst to setDebugLoc. I Create this CallInst , so this CallInst doesn't hava so-called "DebugLoc" mapping to the source

We do something very similar here for XRay, and I would think the approach would be similar. What XRay does are the following: - Find the machine instructions in a MachineFunctionPass that look interesting from the XRay perspective. Theses turn out to be: the beginning of the function (not really an instruction but a location), tail calls, and returns. I suspect you can very simply find the call

On Fri, Dec 2, 2016 at 5:42 PM, Robinson, Paul <paul.robinson at sony.com> wrote: > I've determined that the "pesky" .loc is indeed because of the .cfi > directive that comes immediately after it. Some of the CFI instructions > have source locations, some don't. But, emitting a source location for a > CFI instruction is inappropriate. It's easy enough to

I am programmatically building some functions in intermediate representation, and trying to verify them, but the verifier always reports that there is a problem, and I can't see why. Minimal test case: #ifdef _MSC_VER #pragma warning(disable : 4141) #pragma warning(disable : 4530) #pragma warning(disable : 4624) #endif #include <llvm/IR/IRBuilder.h> #include <llvm/IR/Verifier.h>

On 11 June 2017 at 12:05, Tim Northover <t.p.northover at gmail.com> wrote: > On 11 June 2017 at 11:56, Dipanjan Das via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > I can't pass var_value to a function accepting uint64_t. LLVM complains > > about broken function call. > > Well, yes. var_value has type "ConstantInt *", not uint64_t. Assuming