<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;}
span.EmailStyle22
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal">I can’t help but wonder if the back-and-forth here is largely about naming.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">> <span style="font-family:"Arial",sans-serif">Authors of good-faith optimizations need to design their representations so that transformations that know nothing about their optimizations but merely preserve semantics and well-formed IR
structure will not break their representations<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal">That sounds like a pretty reasonable burden to place on good-faith optimization authors, if I’m following correctly; “preserve semantics and well-formed IR structure” is something we already require of transformations to consider them correct,
right?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I think that some of the points raised come from a more extreme version where “supported_optimizations” are allowed to invent wild new invariants. I wonder if it would help to shift the naming from the optimizations to the annotations.
In particular, the annotations we’re concerned with have been embedded into the semantics of the program. I.e., if I’m following correctly, in the case of the annotations for devirtualization, these launder/strip operations have been written into the value
graph – so there’s not just a store of p anymore, there’s a store of (launder of p), something like that? So I’m wondering if a name like “semantic_annotations” would help – this function’s semantics include some operations that are really no-op annotations
(but any transform that blindly treats them as opaque operations will preserve them sufficiently for the intended consumer). But if you merge such a function into one that hasn’t had the same class of annotations written into its semantics, you get a function
that’s only partially annotated and we need to convey that to the ultimate consumer.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-Joseph<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> cfe-dev <cfe-dev-bounces@lists.llvm.org> <b>On Behalf Of
</b>John McCall via cfe-dev<br>
<b>Sent:</b> Tuesday, December 4, 2018 6:22 PM<br>
<b>To:</b> Philip Reames <listmail@philipreames.com><br>
<b>Cc:</b> llvm-dev <llvm-dev@lists.llvm.org>; Sanjoy Das <sanjoy@playingwithpointers.com>; Clang Dev <cfe-dev@lists.llvm.org>; Richard Smith <RichardSmith@google.com><br>
<b>Subject:</b> Re: [cfe-dev] [llvm-dev] RFC: Supported Optimizations attribute<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p><span style="font-family:"Arial",sans-serif">On 4 Dec 2018, at 17:50, Philip Reames wrote:<o:p></o:p></span></p>
</div>
<div>
<blockquote style="border:none;border-left:solid #777777 1.5pt;padding:0in 0in 0in 4.0pt;margin-left:0in;margin-right:0in;margin-bottom:3.75pt">
<p><span style="font-family:"Arial",sans-serif;color:#777777">Skimming along, apologies if I'm repeating something which already got said.<br>
<br>
If I understand this correctly, the basic problem we're trying to solve is to use a local hint (the invariant.group) to make a global assumption about other code which might exist elsewhere outside the function. The attribute proposed can basically be phrased
as describing a universe of functions within which our desired global property holds. There's an ambiguity about what is allowed to be assumed about code outside that universe.<br>
<br>
I think it's important to note that we have a precedent of something similar to this in TBAA. TBAA information coming from different modules has the same base problem. We solve it by using the "root" of the TBAA tree as a scope descriptor, and essentially
making two TBAA nodes from distinct roots incomparable.<br>
<br>
Can someone explain concisely why a similar scheme couldn't be used to solve this problem?<o:p></o:p></span></p>
</blockquote>
</div>
<div>
<p><span style="font-family:"Arial",sans-serif">TBAA is conservative in <em><span style="font-family:"Arial",sans-serif">two</span></em> ways:<br>
- It allows two accesses to alias if they have TBAA nodes with different roots.<br>
- It allows two accesses to alias if only one of them has a TBAA node.<o:p></o:p></span></p>
<p><span style="font-family:"Arial",sans-serif">The second is what doesn't generalize: there are optimizations where you need to<br>
rely on transition points being explicitly identified. Looking at a function<br>
with no identified transition points, you don't know whether it actually doesn't<br>
transition or whether it was compiled without the transitions being explicitly<br>
marked. There's no way to extend the TBAA idea to make that work.<o:p></o:p></span></p>
</div>
<div>
<blockquote style="border:none;border-left:solid #777777 1.5pt;padding:0in 0in 0in 4.0pt;margin-left:0in;margin-right:0in;margin-bottom:3.75pt">
<p><span style="font-family:"Arial",sans-serif;color:#777777">On 12/4/18 11:24 AM, John McCall via llvm-dev wrote:<o:p></o:p></span></p>
<blockquote style="border:none;border-left:solid #999999 1.5pt;padding:0in 0in 0in 4.0pt;margin-left:0in;margin-right:0in;margin-bottom:3.75pt">
<p><span style="font-family:"Arial",sans-serif;color:#999999">Note that IPO is generally permitted to partially inline or outline code,<br>
and so good-faith optimizations that e.g. require two instructions to be moved<br>
in tandem or not at all must use tokens to establish that unbreakable<br>
relationship.<o:p></o:p></span></p>
</blockquote>
<p><span style="font-family:"Arial",sans-serif;color:#777777">I think the way your framing this is dangerous. We absolutely can not allow any annotation of this form to *weaken* the semantics of the existing IR. We can and should impose a criteria that any
extension of this variety strictly add information to the IR which might not have been previously inferred. We can then design rules for how to preserve our new information as long as possible, but framing this in terms of disallowed transformations is really
a non-starter.<o:p></o:p></span></p>
</blockquote>
</div>
<div>
<p><span style="font-family:"Arial",sans-serif">That's exactly what I was trying to convey here. Authors of good-faith<br>
optimizations need to design their representations so that transformations<br>
that know nothing about their optimizations but merely preserve semantics<br>
and well-formed IR structure will not break their representations. The only<br>
transforms that need to know about the existence of good-faith optimizations<br>
are interprocedural optimizations; furthermore, those optimizations don't<br>
need to know about any good-faith optimizations specifically, they just need<br>
to understand how to correctly update the supported_optimizations list.<br>
That is a very small burden on IPO that enables an interesting class of<br>
language-specific optimizations.<o:p></o:p></span></p>
<p><span style="font-family:"Arial",sans-serif">John.<o:p></o:p></span></p>
</div>
</div>
</div>
</body>
</html>