<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<div class="moz-cite-prefix">On 12/4/18 3:21 PM, John McCall wrote:<br>
</div>
<blockquote type="cite"
cite="mid:2B2578CD-F135-485C-B35C-058680E653F7@apple.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div style="font-family:sans-serif">
<div style="white-space:normal">
<p dir="auto">On 4 Dec 2018, at 17:50, Philip Reames wrote:</p>
</div>
<div style="white-space:normal">
<blockquote style="border-left:2px solid #777; color:#777;
margin:0 0 5px; padding-left:5px">
<p dir="auto">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?</p>
</blockquote>
</div>
<div style="white-space:normal">
<p dir="auto">TBAA is conservative in <em>two</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.</p>
<p dir="auto">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.</p>
</div>
<div style="white-space:normal">
<blockquote style="border-left:2px solid #777; color:#777;
margin:0 0 5px; padding-left:5px">
<p dir="auto">On 12/4/18 11:24 AM, John McCall via llvm-dev
wrote:</p>
<blockquote style="border-left:2px solid #777; color:#999;
margin:0 0 5px; padding-left:5px; border-left-color:#999">
<p dir="auto">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.<br>
</p>
</blockquote>
<p dir="auto">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.</p>
</blockquote>
</div>
<div style="white-space:normal">
<p dir="auto">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.</p>
</div>
</div>
</blockquote>
<p>Two responses:</p>
<p>1) My comment was on *framing*, not substance. I'm not debating
the *semantics* you've proposed (here), just the way they're
described. The way they're described here is very likely to lead
to problematic misinterpretation.</p>
<p>2) Reading back through your description again, it really sounds
like you've reinvented the rules for metadata with an alternate
framing. The only part which is possibly new is the IPO rules you
want to apply. Worth noting is that we already have existing
support for metadata on both instructions and functions. </p>
<p>If we frame all of this as being *metadata*, then your
supported_optimization attribute reduces to the need to define an
intersect rule for metadata on functions during inlining and IPO.
Note that we already have precedence for conservative-by-default
handling at the instruction level, so extending that to the
function scope seems natural.</p>
</body>
</html>