<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 07/09/2014 09:33 PM, Owen Anderson
wrote:<br>
</div>
<blockquote cite="mid:E531CD8B-E83E-4FFD-B085-C97263971645@mac.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<br>
<div>
<div>On Jul 9, 2014, at 3:51 PM, Eric Christopher <<a
moz-do-not-send="true" href="mailto:echristo@gmail.com">echristo@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div style="font-size: 12px; font-style: normal; font-variant:
normal; font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align: start;
text-indent: 0px; text-transform: none; white-space: normal;
widows: auto; word-spacing: 0px; -webkit-text-stroke-width:
0px;">On Wed, Jul 9, 2014 at 3:12 PM, Evan Cheng <<a
moz-do-not-send="true" href="mailto:evan.cheng@apple.com">evan.cheng@apple.com</a>>
wrote:<br>
<blockquote type="cite"><br>
<blockquote type="cite">On Jun 17, 2014, at 2:10 PM, Eric
Christopher <<a moz-do-not-send="true"
href="mailto:echristo@gmail.com">echristo@gmail.com</a>>
wrote:<br>
<br>
<blockquote type="cite">
<blockquote type="cite">2. Metadata compatibility. We
already had precedence of introducing<br>
incompatible changes into metadata format in the
past within release.<br>
Should we use relaxes rules for metadata
compatibility?<br>
</blockquote>
<br>
I think we have a special case for debug metadata (and
should document<br>
that), but otherwise I think we should hold metadata
to the same<br>
standard as the rest of the IR.<br>
<br>
</blockquote>
<br>
The idea with metadata is that it can be removed and
everything still<br>
works. I'm definitely not ready to lock down the debug
metadata format<br>
and I really don't think we should for any of the other
uses since<br>
stripping already works. (Note, I don't consider
function attributes<br>
etc as metadata)<br>
</blockquote>
<br>
We may need to rethink this. If metadata is used only as
optimization / codegen hints, then yes I agree they can be
dropped. But I suspect there is a need for metadata that’s
*required* for correctness. As LLVM continues to gain
clients beyond “just” compilers, we will need to be
sensitive to their needs. I anticipate use of LLVM bitcode
files as persistent object format.<br>
<br>
</blockquote>
<br>
I think that metadata that's required for correctness should
be baked<br>
into the IR and not be metadata - so if there's something we
need for<br>
correctness we need to come up with an IR extension. See the
recent<br>
comdat work as an example.<br>
</div>
</blockquote>
</div>
<br>
<div>That’s not really a practical suggestion for clients that
aren’t essentially clang. The bar to changing the IR is
(correctly) very high, essentially unreachable if the client is
out-of-tree.</div>
</blockquote>
My response as someone with such an out of tree client: that's their
problem. We should consider adding obvious (and merge safe!)
extension points, but we have no responsibility to preserve out of
tree semantics which explicitly go against stated guidelines. <br>
<br>
Also, while the bar for changing the IR is high, I haven't actually
seen that many well thought out proposals rejected. I have also not
seen many rejected without solid reasoning and a recommendation for
a preferred approach. <br>
<br>
Philip<br>
<br>
</body>
</html>