<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:10 PM, Xinliang David
Li via llvm-dev wrote:<br>
</div>
<blockquote
cite="mid:CALRgJCPa_zu6cZgy=3_fcP0H2J-iM3ZwgagZuziVOdOz2HNJ7A@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Oct 27, 2017 at 1:50 AM,
David Chisnall 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">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? </blockquote>
<div><br>
</div>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</div>
</blockquote>
<br>
I agree. Marking external functions from system headers seems like a
reasonable heuristic. We'd need some heuristic because it's not
reasonable for the frontend to know about every function the
optimizer knows about. Over-marking seems okay, however.<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:CALRgJCPa_zu6cZgy=3_fcP0H2J-iM3ZwgagZuziVOdOz2HNJ7A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>David</div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"> 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.<br>
<br>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
David<br>
<div class="HOEnZb">
<div class="h5"><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">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>
><br>
</div>
</div>
<div class="HOEnZb">
<div class="h5">> ______________________________<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>
______________________________<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>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</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>