<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 10, 2014 at 9:08 AM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
> On 2014-Nov-09, at 22:24, Hal Finkel <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:<br>
><br>
> ----- Original Message -----<br>
>> From: "Duncan P. N. Exon Smith" <<a href="mailto:dexonsmith@apple.com">dexonsmith@apple.com</a>><br>
>> To: "LLVM Developers Mailing List" <<a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>><br>
>> Sent: Sunday, November 9, 2014 7:02:43 PM<br>
>> Subject: [LLVMdev] [RFC] Separating Metadata from the Value hierarchy<br>
>><br>
>><br>
>><br>
>> TL;DR: If you use metadata (especially if it's out-of-tree), check<br>
>> the<br>
>> numbered list of lost functionality below to see whether I'm trying<br>
>> to<br>
>> break your compiler permanently.<br>
>><br>
>> In response to my recent commits (e.g., [1]) that changed API from<br>
>> `MDNode` to `Value`, Eric had a really interesting idea [2] -- split<br>
>> metadata entirely from the `Value` hierarchy, and drop general<br>
>> support<br>
>> for metadata RAUW.<br>
>><br>
>> After hacking together some example code, this seems overwhelmingly<br>
>> to<br>
>> me like the right direction. See the attached metadata-v2.patch for<br>
>> my<br>
>> sketch of what the current metadata primitives might look like in the<br>
>> new hierarchy (includes LLVMContextImpl uniquing support).<br>
>><br>
>> The initial motivation was to avoid the API weaknesses caused by<br>
>> having<br>
>> non-`MDNode` metadata that inherits from `Value`. In particular,<br>
>> instead of changing API from `MDNode` to `Value`, change it to a base<br>
>> class called `Metadata`, which sheds the underused and expensive<br>
>> `Value`<br>
>> base class entirely.<br>
>><br>
>> The implications are broader: an enormous reduction in complexity<br>
>> (and<br>
>> overhead) for metadata.<br>
>><br>
>> This change implies minor (major?) loss of functionality for<br>
>> metadata,<br>
>> but Eric and I suspect that the only hard-to-fix user is debug info<br>
>> itself, whose IR infrastructure I'm rewriting anyway.<br>
>><br>
>> Here is what we'd lose:<br>
>><br>
>> 1. No more arbitrary RAUW of metadata.<br>
>><br>
>> While we'd keep support for RAUW of temporary MDNodes for use as<br>
>> forward declarations (when parsing assembly or constructing cyclic<br>
>> graphs), drop RAUW support for all other metadata.<br>
><br>
> 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?<br>
><br>
> 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.<br>
><br>
> Thanks again,<br>
> Hal<br>
<br>
</div></div>So, none of them would be `Value`s.<br>
<br>
`TempMDNode` supports its own, non-`Value`-based, RAUW via<br>
`ReplaceableMetadataImpl` (`ValueAsMetadata` uses the same).<br>
<br>
`CloneAliasScopeMetadata()` should use `TrackingMDRef` in place of<br>
`TrackingVH<MDNode>`. `TrackingMDRef` will register itself with the<br>
`Metadata` if it's replaceable, and if/when it gets RAUW'ed, the pointer<br>
will get updated.<br>
<br>
If you have another look at the patch it might be more clear now.<br>
<br>
BTW, another thing I added in that sketch was the option to explicitly<br>
request a non-uniqued `MDNode`. Haven't thought through details, but I<br>
was specifically thinking this would be a cleaner way to create your<br>
non-uniquable alias nodes (instead of the current self-referential<br>
approach).<br>
<br>
My working straw man for assembly syntax looks like this:<br>
<br>
!1 = metadata distinct !{ ... }<br>
<br>
As an example, the alias "root" nodes could change from this:<br>
<br>
!1 = metadata !{ metadata !1 }<br>
<br>
to this:<br>
<br>
!1 = metadata distinct !{}<br>
<br>
Which means constructing them would change from this:<br>
<br>
MDNode *T = MDNode::getTemporary(Context, None)<br>
MDNode *N = MDNode::get(Context, {T});<br>
T->replaceAllUsesWith(N);<br>
MDNode::deleteTemporary(T);<br>
<br>
to this:<br>
<br>
// In that patch it's "getNonUniqued()".<br>
MDNode *N = MDNode::getDistinct(Context, None);<br>
<br>
Furthermore, if all references to the alias root got dropped, they'd<br>
clean themselves up instead of keeping each other alive in a cycle.<br></blockquote><div><br>There are at least two bugs I know of in debug info that are due to overzealous metadata uniqing:<br><br>1) inline two calls to the same function on the same line and we end up with one inlined call (inlined location + original location are the same, so the scope becomes one scope instead of two). We workaround this in the frontend by adding column info to calls (but we don't do it for constructor calls or member function calls... ) but any workaround is insufficient as, in the limit, you can put the two calls in a macro and then they'll be attributed to the same line and column. (I cc'd you on a bug about this a week or two ago)<br><br>2) two anonymous structs in the same location (again, even adding column info doesn't save you from a macro) end up as one struct... (which gets weird with duplicate members, etc)<br><br>There could easily be others, too. <br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div></div>