similar to: How to insert instructions before each function calls?

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

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

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 5 Sep 2016, at 16:14, SHUCAI YAO <yaos4 at mcmaster.ca> wrote: > > > Hi Dean, > > Do you have any example for this? I would like have a look at how you handle this in XRay if it is possible. > Yes, this is all upstream -- if you look in lib/CodeGen/XRayInstrument.cpp and the associated lowering code for X86 in lib/Target/X86/X86MCInstLower.cpp and/or search

> On 5 Sep 2016, at 11:49, SHUCAI YAO <yaos4 at mcmaster.ca> wrote: > > For the function call lowering, do you mean lowercall function? I did insert the instruction before the stack adjustments, but the inserted code appears in the prologue of the function, other than before the function call. Maybe I did something wrong with the iterator. > > So you mean I should insert a

> 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

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 insertion point of an IRBuilder sets the builder’s current debug loc to the one attached to the insertion point. IMO this isn't always a correct or convenient thing to do, and it shouldn't be the default behavior.

> 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, 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)]

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 =

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

On Mar 23, 2012, at 4:29 PM, Paul J. Lucas wrote: > On Mar 23, 2012, at 3:25 PM, Bill Wendling wrote: > >> Let's take your example. You will have code that looks like this: >> >> extern "C" void thunk_item_M_delete( void *v_that ) { >> item *that = 0; >> try { >> that = static_cast<item*>( v_that ); >>

I have a question about inserting instructions into the LLVM IR. I can insert instructions, but my operands do not have the right type, so it fails an assertion at runtime. I am trying to insert an immediate load instructions, as a means of claiming a new register. Here is what I do: Builder.SetInsertPoint(LLVMBB, I); // The following line looks to me like it would have a chance of loading

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)

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

(2) cause CFI instructions not to emit any .loc directives; done in r289256, plus r289288 (3) file a bug to have someone audit LoopVectorizer.cpp to see whether it is using SetCurrentDebugLocation in the right places; haven't done that part yet (4) reapply my "line 0" patch, which will be the 3rd attempt. r289468 Please ping me when you do (4). Also, will there be a flag to disable

There is already –mllvm –use-unknown-locations which ought to trigger this. Don't need my patch. --paulr From: Kostya Serebryany [mailto:kcc at google.com] Sent: Thursday, December 01, 2016 4:08 PM To: Robinson, Paul Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Libfuzzer depending on uninitialized debug info On Thu, Dec 1, 2016 at 3:37 PM, Robinson, Paul <paul.robinson at

> Note that C bindings have been introduced since 2005, so there may be > a different route available than was taken then. Look in include/llvm- > c. The intent of the C bindings is to enable high-level language > bindings. The current focus is on enabling front-end compilers. Ocaml > and Haskell bindings have been developed atop them, the former being > in the LLVM source

If you want an immediate constant value, ConstantInt::get(APInt(32, 5, false)) will perhaps help you ? Olivier. 2009/5/5 seventh moon <suigintou_ at hotmail.com> > I have a question about inserting instructions into the LLVM IR. I can > insert instructions, but my operands do not have the right type, so it fails > an assertion at runtime. > > I am trying to insert an