[LLVMdev] [RFC] Separating Metadata from the Value hierarchy

Hal Finkel hfinkel at anl.gov
Sun Nov 9 22:24:20 PST 2014


----- Original Message -----
> From: "Duncan P. N. Exon Smith" <dexonsmith at apple.com>
> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
> Sent: Sunday, November 9, 2014 7:02:43 PM
> Subject: [LLVMdev] [RFC] Separating Metadata from the Value hierarchy
> 
> 
> 
> 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 metadata RAUW.
> 
> After hacking together some example code, this seems overwhelmingly
> to
> me like the right direction. See the attached metadata-v2.patch for
> my
> sketch of what the current metadata primitives might look like in the
> new hierarchy (includes LLVMContextImpl uniquing support).
> 
> The initial motivation was to avoid the API weaknesses caused by
> having
> non-`MDNode` metadata that inherits from `Value`. In particular,
> instead of changing API from `MDNode` to `Value`, change it to a base
> class called `Metadata`, which sheds the underused and expensive
> `Value`
> base class entirely.
> 
> The implications are broader: an enormous reduction in complexity
> (and
> overhead) for metadata.
> 
> This change implies minor (major?) loss of functionality for
> metadata,
> but Eric and I suspect that the only hard-to-fix user is debug info
> itself, whose IR infrastructure I'm rewriting anyway.
> 
> Here is what we'd lose:
> 
> 1. No more arbitrary RAUW of metadata.
> 
> While we'd keep support for RAUW of temporary MDNodes for use as
> forward declarations (when parsing assembly or constructing cyclic
> graphs), drop RAUW support for all other metadata.

So temporary MDNodes would be Values, but regular metadata would not be? Will regular metadata nodes no longer have lists of users? If I have a TrackingVH<MDNode> with temporary MDNodes, after I call replaceAllUsesWith, what happens?

I'm specifically wondering how we'll need to update CloneAliasScopeMetadata in lib/Transforms/Utils/InlineFunction.cpp, and I don't see any fundamental problem with what you've proposed, but these seem like generic upgrade questions.

Thanks again,
Hal

> 
> Note that we'd also keep support for RAUW of `Value` operands of
> metadata.
> 
> If the RAUW of an operand causes a uniquing collision, uniquing
> would be dropped for that node. This matches the current behaviour
> when an operand goes to null.
> 
> Upgrade path: none.
> 
> 2. No more function-local metadata.
> 
> AFAICT, function-local metadata is *only* used for indirect
> references to instructions and arguments in `@llvm.dbg.value` and
> `@llvm.dbg.declare` intrinsics. The first argument of the following
> is an example:
> 
> call void @llvm.dbg.value(metadata !{i32 %val}, metadata !0,
> metadata !1)
> 
> Note that the debug info people uniformly seem to dislike the status
> quo, since it's awkward to get from a `Value` to the corresponding
> intrinsic.
> 
> Upgrade path: Instead of using an intrinsic that references a
> function-local value through an `MDNode`, attach metadata to the
> corresponding argument or instruction, or to the terminating
> instruction of the basic block. (This requires new support for
> attaching metadata to function arguments, which I'll have to add for
> debug info anyway.)
> 
> Is this going to break your compiler? How? Why is your use case worth
> supporting?
> 
> [1]:
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141103/242667.html
> "r221167 - IR: MDNode => Value:
> Instruction::getAllMetadataOtherThanDebugLoc()"
> [2]:
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-November/078581.html
> "Re: First-class debug info IR: MDLocation"
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory



More information about the llvm-dev mailing list