search for: valuemapping

Hi there, I added a function to a module, but failed to write the bitcode to file because it hit the: assert(I != ValueMap.end() && "Value not in slotcalculator!") So I added some diagnosis information there, unsigned ValueEnumerator::getValueID(const Value *V) const { if (isa<MDNode>(V) || isa<MDString>(V)) { ValueMapType::const_iterator I =

After cloning a Module with CloneModule, there doesn't seem to be any easy way to convert a Value pointing into the old Module to a Value pointing into the new one. The CloneModule implementation already has to keep such a mapping internally, so I've written a patch that exposes it as a second inout parameter to CloneModule(), with the one param version being a simple wrapper for backward

Hi all, I am trying to write a pass where i am creating a clone of a function (the only difference being, the new function returns void , instead of any value). I am creating a new Function Type with a void return type (rest being the same as original function), and using this i am creating a new function body. Then, i clone the body of the old function into new function, but when ever i

Hi, I have a question about llvm/ADT/DenseMap.h and llvm/IR/ValueMap.h: When you have a: MapType M; is it safe to do: M[NewKey] = M[OldKey]; or do you need to do it in two steps: auto tmp = M[OldKey]; // ensure the reference to M[OldKey] is copied, before reassigning. M[NewKey] = tmp; // might reallocate aka, will a possible allocation for M[NewKey] invalidate the

Hi, I'm gonna try to give some feedback, but I have only been working with LLVM for a few days, so don't take what I'm saying without verifying :-) > BasicBlock *ProgSlicer::CloneBasicBlock(const BasicBlock *BB, > DenseMap<const Value*, Value*> &ValueMap, > const char *NameSuffix, Function *F) { > > BasicBlock

> On 2014 Dec 10, at 08:40, Tom Stellard <tom at stellard.net> wrote: > > On Tue, Dec 09, 2014 at 09:22:16PM -0800, Duncan P. N. Exon Smith wrote: >> The `Metadata`/`Value` split (PR21532) landed in r223802 -- at least, the >> C++ side of it. This was a rocky day, but I suppose that's what I get >> for failing to stage the change in smaller pieces. >>

2013/3/27 Nick Lewycky <nicholas at mxc.ca>: >The common idiom to delete any Value* is: > > V->replaceAllUsesWith(UndefValue::get(V->getType()); > V->eraseFromParent(); > > Does that work for functions? You may need to make sure the 'undef' has a > pointer to function type instead of the function type. > I tried this code sample, passing the type

Hi all, I'm rather new to LLVM and intend to dive into partial evaluation with LLVM. I tried to run the example from http://llvm.org/devmtg/2008-08-23/llvm_partial.pdf, which worked after some adaptations, which were necessary, because LLVM evolved since the slides were made. However, I also tried to get the same example running as an optimization pass following the instructions in

Hello Visual Studio is complaining about the mix of struct and class. 2>C:\dev\llvm\include\llvm/ADT/ValueMap.h(202) : warning C4099: 'llvm::DenseMapInfo<llvm::ValueMapCallbackVH<KeyT,ValueT,Config,ValueInfoT>>' : type name first seen using 'struct' now seen using 'class' 2> C:\dev\llvm\include\llvm/ADT/ValueMap.h(251) : see reference to class

Hi Guoliang, > I added a function to a module, but failed to write the bitcode to file > because it hit the: > assert(I != ValueMap.end()&& "Value not in slotcalculator!") does the module pass the verifier after you add the function to it? Ciao, Duncan.

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

> On 2014 Dec 10, at 14:08, Tom Stellard <tom at stellard.net> wrote: > > On Wed, Dec 10, 2014 at 11:21:08AM -0800, Duncan P. N. Exon Smith wrote: >> >>> On 2014 Dec 10, at 08:40, Tom Stellard <tom at stellard.net> wrote: >>> >>> On Tue, Dec 09, 2014 at 09:22:16PM -0800, Duncan P. N. Exon Smith wrote: >>>> The `Metadata`/`Value`

The `Metadata`/`Value` split (PR21532) landed in r223802 -- at least, the C++ side of it. This was a rocky day, but I suppose that's what I get for failing to stage the change in smaller pieces. As of r223916 (lldb), I'm not aware of any remaining (in-tree) breakage, so if I've missed some problem in the sea of buildbot errors, please flag me down. I'll follow up soon with

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

On Wed, Dec 10, 2014 at 05:27:45PM -0800, Duncan P. N. Exon Smith wrote: > +zalman at google.com > Hi Duncan, This patch plus another small change fixes the assertion failure for me. With the patch alone, the void* overload of addGarbageObject() was being used by MDNode::getTemporary(), so I had to cast the object as an MDNode*: diff --git a/lib/IR/Metadata.cpp b/lib/IR/Metadata.cpp

I actually ran into an elusive bug with this exact same issue some time ago as well, see https://bugs.llvm.org/show_bug.cgi?id=42065 and https://reviews.llvm.org/D62624. The strange thing about that bug was that it only showed up if built with GCC; Clang dereferenced the right hand side reference before evaluating the left hand side, as long as the value type was as small as the reference

I committed: r224058 = 966942da9e68b59c31ce770e7f94c55a63482c6b r224060 = da75f7277e3a129aed8ef8aa4e0d84de40b76fd4 r224061 = f88e4c8e9171045454b2c8e05054c2af8da3fe4f Let me know if somehow you're still hitting the problem. r224061 removes leak detection entirely from `MachineInstr`. There aren't any leaks to be had there, since they're allocated in a custom allocator. They're

On Friday 11 July 2008 12:05, Devang Patel wrote: > > 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 call these clones > > "pristine" > > functions. > > > > 2. After all processing is done, clone the resulting

Hello Teresa, Thank you for your analysis. One thing to note is that the global materializer materializes the value as a function declaration, not a function definition. As I pasted on my first email, ; Materializable ; Function Attrs: nounwind uwtable define weak_odr void @foo(%1*) unnamed_addr #7 comdat($comdat1) align 2 personality i32 (...)* @__gxx_personality_v0 {} is materialized to ;