<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 10/27/2017 01:27 PM, David Majnemer
via llvm-dev wrote:<br>
</div>
<blockquote
cite="mid:CAL7bZ_co4aQUW-kfOo3sOYfgV=KGOTyK0qXfxP8Y_BAr9qgnow@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr">In general, I think we are better off phrasing
attributes as giving optimization power rather than restricting
it. It allows for a naive optimization pass to avoid considering
attributes at all.</div>
</blockquote>
<br>
I think that's what's being proposed. nobuiltin does not follow our
general conventions in this regard, whereas this new thing would.<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:CAL7bZ_co4aQUW-kfOo3sOYfgV=KGOTyK0qXfxP8Y_BAr9qgnow@mail.gmail.com"
type="cite">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Oct 27, 2017 at 11:15 AM,
Robinson, Paul via llvm-dev <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div class="m_-2289522079602024581WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">+1
to what the Davids said. This could also help
address the situation that the Android keynote
mentioned at last week's dev meeting: if you're
building the implementation of the library you don't
want the compiler to wave its magic wand because it
knows better than you.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">--paulr</span></p>
<p class="MsoNormal"><a moz-do-not-send="true"
name="m_-2289522079602024581__MailEndCompose"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></a></p>
<div style="border:none;border-left:solid blue
1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #b5c4df
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
llvm-dev [mailto:<a moz-do-not-send="true"
href="mailto:llvm-dev-bounces@lists.llvm.org"
target="_blank">llvm-dev-bounces@<wbr>lists.llvm.org</a>]
<b>On Behalf Of </b>Xinliang David Li via
llvm-dev<br>
<b>Sent:</b> Friday, October 27, 2017 11:11 AM<br>
<b>To:</b> David Chisnall<br>
<b>Cc:</b> llvm-dev<br>
<b>Subject:</b> Re: [llvm-dev] RFC: We need to
explicitly state that some functions are
reserved by LLVM</span></p>
</div>
</div>
<div>
<div class="h5">
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">On Fri, Oct 27, 2017 at
1:50 AM, David Chisnall via llvm-dev <<a
moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org"
target="_blank">llvm-dev@lists.llvm.org</a>>
wrote:</p>
<p class="MsoNormal">This seems slightly
inverted. As I understand it, the root of
the problem is that some standards, such
as C, C++, and POSIX, define some
functions as special and we rely on their
specialness when optimising.
Unfortunately, the specialness is a
property of the source language and,
possibly, environment and not necessarily
of the target. The knowledge of which
functions are special seems like it ought
to belong in the front end, so a C++
compiler might tag a function called _Znwm
as special, but to a C or Fortran front
end this is just another function and
shouldn’t be treated specially.<br>
<br>
Would it not be cleaner to have the front
end (and any optimisations that are aware
of special behaviour of functions) add
metadata indicating that these functions
are special? </p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Ideally many of these
functions should be annotated as builtin
in the system headers. An hacky
solution is for frontend to check if the
declarations are from system headers to
decide if metadata needs to be applied.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">David</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<blockquote
style="border:none;border-left:solid
#cccccc 1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"
style="margin-bottom:12.0pt">If the
metadata is lost, then this inhibits
later optimisations but shouldn’t affect
the semantics of the code (it’s always
valid to treat the special functions as
non-special functions) and optimisations
then don’t need to mark them. This
would also give us a free mechanism of
specifying functions that are
semantically equivalent but have
different spellings.</p>
</blockquote>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<blockquote
style="border:none;border-left:solid
#cccccc 1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">David</p>
<div>
<div>
<p class="MsoNormal"><br>
> On 27 Oct 2017, at 04:14,
Chandler Carruth via llvm-dev <<a
moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org"
target="_blank">llvm-dev@lists.llvm.org</a>>
wrote:<br>
><br>
> I've gotten a fantastic bug
report. Consider the LLVM IR:<br>
><br>
> target triple =
"x86_64-unknown-linux-gnu"<br>
><br>
> define internal i8* @access({
i8* }* %arg, i64) {<br>
> ret i8* undef<br>
> }<br>
><br>
> define i8* @g({ i8* }* %arg) {<br>
> bb:<br>
> %tmp = alloca { i8* }*, align
8<br>
> store { i8* }* %arg, { i8*
}** %tmp, align 8<br>
> br i1 undef, label %bb4,
label %bb1<br>
><br>
> bb1:<br>
> %tmp2 = load { i8* }*, { i8*
}** %tmp, align 8<br>
> %tmp3 = call i8* @access({
i8* }* %tmp2, i64 undef)<br>
> br label %bb4<br>
><br>
> bb4:<br>
> ret i8* undef<br>
> }<br>
><br>
> This IR, if compiled with `opt
-passes='cgscc(inline,<wbr>argpromotion)'
-disable-output` hits a bunch of
asserts in the LazyCallGraph.<br>
><br>
> The problem here is that
`argpromotion` turns a normal
looking function `i8* @access({ i8*
}* %arg, i64)` and turn it into a
magical function `i8* @access(i8*
%arg, i64)`. This latter signature
is the POSIX `access` function that
LLVM's `TargetLibraryInfo` knows
magical things about.<br>
><br>
> Because *some* library
functions known to
`TargetLibraryInfo` can have *calls*
to them introduced at arbitrary
points of optimization (consider
vectorized variants of math
functions), the new pass manager and
its graph to provide ordering over
the module get Very Unhappy when you
*introduce* a definition of a
library function in the middle of
the compilation pipeline.<br>
><br>
> And really, we do *not* want
`argpromotion` to do this. We don't
want it to turn some random function
by the name of `@free` into the
actual `@free` function and suddenly
change how LLVM handles it.<br>
><br>
> So what do we do?<br>
><br>
> One option is to make
`argpromotion` and every other pass
that mutates a function's signature
rename the function (or add a
`nobuiltin` attribute to it).
However, this seems brittle and
somewhat complicated.<br>
><br>
> My proposal is that we admit
that certain names of functions are
reserved in LLVM's IR. For these
names, in some cases *any* function
with that name will be treated
specially by the optimizer. We can
still check the signatures when
transforming code based on LLVM's
semantic understanding of that
function, but this avoids any need
to check things when mutating the
signature of the function.<br>
><br>
> This would require frontends to
avoid emitting functions by these
names unless they should have these
special semantics. However, even if
they do, everything should remain
conservatively correct. But I'll
send an email to cfe-dev suggesting
that Clang start "mangling" internal
functions that collide with target
names. I think this is important as
I've found a quite surprising number
of cases where this happens in real
code.<br>
><br>
> There is no need to
auto-upgrade here, because again,
LLVM's handling will remain
conservatively correct.<br>
><br>
> Does this seem reasonable? If
so, I'll send patches to update the
LangRef with these restrictions.
I'll also take a quick stab at
generating some example tables of
such names from the .td files used
by `TargetLibraryInfo` already.
These can't be authoritative because
of the platform-specific nature of
it, but should help people
understand how this area works.<br>
><br>
><br>
> One alternative that seems
appealing but doesn't actually help
would be to make `TargetLibraryInfo`
ignore internal functions. That is
how the C++ spec seems to handle
this for example (C library function
names are reserved only when they
have linkage). But this doesn't work
well for LLVM because we want to be
able to LTO an internalized C
library. So I think we need the rule
for LLVM function names to not rely
on linkage here.<br>
><br>
><br>
> Thanks,<br>
> -Chandler<br>
></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">>
______________________________<wbr>_________________<br>
> LLVM Developers mailing list<br>
> <a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org"
target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a moz-do-not-send="true"
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
target="_blank">
http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org"
target="_blank">llvm-dev@lists.llvm.org</a><br>
<a moz-do-not-send="true"
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a moz-do-not-send="true"
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>