search for: trackingvh

Hi all, I'm currently using llvm::TrackingVH in order to have a tracking reference to a definition. Unfortunately, TrackingVHs are incredibly slow. Are there alternatives? -- Roland

...ues off to the side. - We link two Modules together The data structure is a map from one IR to another, so when we see objects in one IR we know which LLVM Values represent them. Somehow the data structure needs to be updated with the new Values created as a result of the linking. I was hoping a TrackingVH could do this but it's not enough. For one thing, RAUW is not called for everything during linking, specifically, when copying from the source module. To my surprise LLVM actually creates whole new Values in some cases and just copies the bits from the source Module Value to the new Value. R...

...+ 3933 8 clang 0x00000001008018b2 llvm::DenseMap<llvm::SDNode const*, unsigned int, llvm::DenseMapInfo<llvm::SDNode const*>, llvm::DenseMapInfo<unsigned int> >::clear() + 1154 9 clang 0x0000000100837678 llvm::SmallVectorTemplateBase<std::pair<llvm::TrackingVH<llvm::MDNode>, std::pair<unsigned int, llvm::DebugLoc> >, false>::grow(unsigned long) + 6296 10 clang 0x0000000100836e2f llvm::SmallVectorTemplateBase<std::pair<llvm::TrackingVH<llvm::MDNode>, std::pair<unsigned int, llvm::DebugLoc> >, false>::g...

...Modules together > > The data structure is a map from one IR to another, so when we see > objects in one IR we know which LLVM Values represent them. Somehow the > data structure needs to be updated with the new Values created as a > result of the linking. > > I was hoping a TrackingVH could do this but it's not enough. For one > thing, RAUW is not called for everything during linking, specifically, > when copying from the source module. To my surprise LLVM actually > creates whole new Values in some cases and just copies the bits from the > source Module Value...

TL;DR: If you use metadata (especially if it's out-of-tree), check the numbered list of lost functionality below to see whether I'm trying to break your compiler permanently. In response to my recent commits (e.g., [1]) that changed API from `MDNode` to `Value`, Eric had a really interesting idea [2] -- split metadata entirely from the `Value` hierarchy, and drop general support for

...or use as >> forward declarations (when parsing assembly or constructing cyclic >> graphs), drop RAUW support for all other metadata. > > This seems fine to me, a corollary of this should be that MDNodes never “move around” in memory due to late uniquing etc, which means that TrackingVH shouldn’t be necessary, right? This should make all frontends a lot more memory efficient because they can just use raw pointers to MDNodes everywhere. Almost. Two caveats: 1. Handles should generally be `MDRef` instead of `Metadata*`, since I threw in reference-counting semantics so that...