<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 11/09/2014 05:02 PM, Duncan P. N.
Exon Smith wrote:<br>
</div>
<blockquote
cite="mid:AA382222-F630-4715-862A-AED67BC2F160@apple.com"
type="cite">
<pre wrap="">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.</pre>
</blockquote>
I generally support this direction. I do not know of any current
use case which would be broken by this change. I do have some
hesitations about potential future use though. (see below)<br>
<blockquote
cite="mid:AA382222-F630-4715-862A-AED67BC2F160@apple.com"
type="cite">
<pre wrap="">
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.
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)
</pre>
</blockquote>
I hesitate a bit here. The current range metadata deals only with
constant ranges, but I could see a day where encoding a range in
terms of two other Values might be useful. This is one obvious use
case, but there may also be others.<br>
<br>
I'm not going to oppose the proposal made, but if there was a way to
preserve the ability to reference to function local SSA values, I'd
slightly prefer that. <br>
<blockquote
cite="mid:AA382222-F630-4715-862A-AED67BC2F160@apple.com"
type="cite">
<pre wrap="">
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]: <a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141103/242667.html">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141103/242667.html</a>
"r221167 - IR: MDNode => Value: Instruction::getAllMetadataOtherThanDebugLoc()"
[2]: <a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-November/078581.html">http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-November/078581.html</a>
"Re: First-class debug info IR: MDLocation"
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a class="moz-txt-link-freetext" href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
</blockquote>
<br>
</body>
</html>