<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Honestly, I think well defined nulls are a complete different
problem, and the approach taken by the null-pointer-is-valid
attribute is simply wrong. We have existing mechanisms for this
(data layout, implicit null checks, etc..), and don't need a
separate attribute on the function.</p>
<p>Philip<br>
</p>
<div class="moz-cite-prefix">On 12/5/18 2:31 AM, Piotr Padlewski
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAEhrgAPkVrYiFbdpHDn-9ojOL7DJvaC-aDccqjYMnTxQBVVNGQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">An additional bit to the discussion:<b> </b>I
think that <b>"null-pointer-is-valid"</b> attribute should
also be handled in a similar manner - if one function
calls</div>
<div>another one marked with <b>"null-pointer-is-valid"</b>,
then after inlining the function should also be marked
with<b> "null-pointer-is-valid"</b>.</div>
<div>I assume this attribute was added to handle kernel or
embedded code correctly and probably there was no use
case to do LTO between </div>
<div>modules with and without this attribute (yet).</div>
<div>This, unfortunately, can't be solved with our <b>supported_optimizations</b>
attribute, as null pointer dereference is considered to be
UB by default. </div>
<div>We would need something like <b>"unsupported_optimizations"</b>,
but I think this shows that this is not the last time when
a similar problem will arise.</div>
<div><br>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">śr., 5 gru 2018 o 09:57 Piotr Padlewski <<a
href="mailto:piotr.padlewski@gmail.com"
moz-do-not-send="true">piotr.padlewski@gmail.com</a>>
napisał(a):<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<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"
target="_blank" 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>
<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>
</div>
</blockquote>
</body>
</html>