<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/5/18 12:57 AM, Piotr Padlewski
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAEhrgAMF4p=dhrAsG0oTQZKnGbFUu+Vvj0aFdzy_HZ_E6tTYcw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr"><br>
<br>
<div class="gmail_quote">
<div dir="ltr">śr., 5 gru 2018 o 00:22 John McCall via cfe-dev
<<a href="mailto:cfe-dev@lists.llvm.org"
moz-do-not-send="true">cfe-dev@lists.llvm.org</a>>
napisał(a):<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<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>
</div>
</blockquote>
<div>The other reason why similar scheme doesn't work for
!invariant.group is that we rely on a calls to launder/strip
being present for some constructs to preserve</div>
<div>information about invartianess of an object (like in the
example from RFC).</div>
</div>
</div>
</blockquote>
<p>I'm really not sure I buy this. You're effectively saying that
you have two points which need to share a common root: 1) the
"transition point" and 2) the invariant.group marker. If it were
possible to mark the transition point with a metadata node - is
it? - the exact same rules as used for TBAA work just fine. <br>
</p>
<p>p.s. It would help me a lot if you'd spell out specific examples
of transition points. I checked the RFC and don't see them.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAEhrgAMF4p=dhrAsG0oTQZKnGbFUu+Vvj0aFdzy_HZ_E6tTYcw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div style="font-family:sans-serif">
<div style="white-space:normal">
</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>
<p dir="auto">John.</p>
</div>
</div>
</div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank"
moz-do-not-send="true">cfe-dev@lists.llvm.org</a><br>
<a
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote>
</div>
</div>
</blockquote>
</body>
</html>