similar to: [LLVMdev] CloneFunctionInto() overwrites alignment attribute

Hi John, thanks for the pointer. However, I'd rather avoid rolling a custom implementation. After all, it's not like I want to do something drastically different... I had sorted out the problem for 3.2 as well as a previous version of 3.3 trunk, but the API changed about a hundred times. Now as it apparently has stabilized, I moved to a the 3.3 release branch just to find that even

Hi, I am again struggling to find my way around the Attribute classes. What I want to do is clone a function into a declaration where some parameters may have a different alignment. CloneFunctionInto in debug mode hits an assertion which is marked with a FIXME (Attributes.cpp:673). I would be totally fine with any kind of workaround, e.g. removing all attributes from the target declaration,

On 5/15/13 10:27 AM, Ralf Karrenberg wrote: > Hi, > > I am again struggling to find my way around the Attribute classes. > What I want to do is clone a function into a declaration where some > parameters may have a different alignment. > CloneFunctionInto in debug mode hits an assertion which is marked with > a FIXME (Attributes.cpp:673). > I would be totally fine with

I was just going to say: With well-formed debug info it should create a deep copy up until the DISubprogram, but no further. But because the DISubprogram linked to the Function is missing the special handling of the DISubprogram (that would prohibit cloning the DICompileUnit is side-stepped). But then I remembered the discussion we had in

Dear All, I need your help urgently I have to copy the CFG of each function using CloneFunction or CloneFunctionInto. After I made the copy function. Print the basic blocks then get this error : While deleting: i32 % Use still stuck around after Def is destroyed: %mul2_ = mul nsw i32 %6, 3 Use still stuck around after Def is destroyed: store i32 3, i32* %x_, align 4 opt: Value.cpp:75: virtual

Does cloning copies the function with its address or it constructs a new address to the new function? Is this real copying for the CFG or just opaque one to do some work? If it's not real copying, please I need a method that can help me in copying the function in another with new pointer to another address. Please I need answer urgent Thanks On 29 May 2013 10:14, Rasha Omar <rasha.sala7

The if you are cloning into the same LLVM module the CU should not cloned. If don't mind sharing your code, I can try to help diagnose why the CU gets cloned... just send me a patch that applies to trunk and instructions. -- adrian > On Jun 16, 2017, at 1:54 PM, Sergei Larin <slarin at codeaurora.org> wrote: > > Sorry… It takes a pass that was not accepted for upstreaming….

This all looks very similar to a bug in the cloning stuff I fixed recently, so would be indeed good to know if this is still happening on master. On Thu, Jun 15, 2017 at 2:23 PM, Adrian Prantl via llvm-dev < llvm-dev at lists.llvm.org> wrote: > If you are doing this work based off LLVM trunk, could you send me your > patch to reproduce the problem? > > -- adrian > > On

Can you send me a patch with instructions to reproduce? I can take a look. -- adrian > On Jun 15, 2017, at 2:23 PM, Sergei Larin <slarin at codeaurora.org> wrote: > > Yes, it does for us. My tree is couple days off the tip, and I see it there. > > Sergei > > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Keno Fischer via llvm-dev > Sent:

Hi! We are currently working on a science project and implemented a FunctionPass that clones a function (more precisely a constructor of a struct/class) and adds a parameter. First, we create a new function with a new function type, which includes the newly added parameter: Function *NF = Function::Create(NewFTy, F.getLinkage(), F.getName() + "Cloned", F.getParent()); and after

- old Keno +current Keno > On Jun 19, 2017, at 2:59 PM, Adrian Prantl <aprantl at apple.com> wrote: > > In your example the instructions in the cloned function have debug locations belonging to a different function, and the function itself is missing a DISubprogram metadata attachment. > >> (lldb) p OldFunc->dump() >> >> ; Function Attrs: nounwind optsize

On Wednesday 09 July 2008 13:49, David Greene wrote: > > then it seems you're doing > > > > for each function > > generate_ir > > convert_to_llvm_ir > > optimize_llvm_ir > > Yep. Ok, I've mostly got a mechanism to do what I want: 1. As each function comes in for op/codegen, clone it and save off the clone and its associated ValueMap (I

On 14 July 2016 at 20:07, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Jul 14, 2016, at 7:58 AM, Pierre Gagelin via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Hi, > > I am trying to use the CloneFunction from llvm/Transforms/Utils/Cloning.h > and I don't understand how the ValueToValueMapTy argument should be > initialized. For instance,

Hello All, I am having a problem with using CloneFunctionInto to clone a function that includes changing the type of a value using the VMap. Specifically, I am using the VMap to change the address space of values that have particular pointer types. The problem seems to be that RemapInstruction successfully changes the operands using the VMap, but the VTy member indicating the type of the

I'm trying to create a clone of a function using Function::Create() and CloneFunctionInto. However, I'm running into an issue. I believe that the instructions in the function clone still have Use edges to values in the original function. This is a problem for my purposes. For example, consider an original function F. I create a new function G belonging to the same module and call

Hi all, Sorry for the inconvenient about the previous post. The files were not attached. So I put them here again. I am a newbie in LLVM and I am trying to replace the function like: old function || new function ============================== ========= int haha(int a) { int haha(int a, char* ID) { ===> }

On Wednesday 09 July 2008 13:24, Devang Patel wrote: > Is it possible to explain intended use of original unoptimized version ? bugpoint. I want to run it on the IR produced by our frontend. This will help us generate new LLVM tests we can send upstream. We've fixed bugs that aren't caught by the upstream tests and it would be nice to capture the problem and make the test

Hi Philip, Thanks for the reference, I was able to follow it and copy the code that I saw necessary, but I still have some issues (references are still not updated). I created the function: void populateVMap(llvm::ValueToValueMapTy &VMap, llvm::Function *fOld, llvm::Function *fNew) { llvm::Function::arg_iterator DestI = fOld->arg_begin(); for (llvm::Function::const_arg_iterator J =

Hi Philip, The error happens when the program finishes and it automatically calls the destructors, so it is not an error specifically inside my program. Here's the full code: #include "llvm/ExecutionEngine/ExecutionEngine.h" #include "llvm/ExecutionEngine/MCJIT.h" #include "llvm/IRReader/IRReader.h" #include "llvm/Support/TargetSelect.h" #include

On Jul 11, 2008, at 9:59 AM, David Greene wrote: > On Wednesday 09 July 2008 13:49, David Greene wrote: > >>> then it seems you're doing >>> >>> for each function >>> generate_ir >>> convert_to_llvm_ir >>> optimize_llvm_ir >> >> Yep. > > Ok, I've mostly got a mechanism to do what I want: > > 1. As