[llvm-dev] RFC: We need to explicitly state that some functions are reserved by LLVM

Fri Oct 27 11:27:51 PDT 2017

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.

On Fri, Oct 27, 2017 at 11:15 AM, Robinson, Paul via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> +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.
>
> --paulr
>
>
>
> *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of *Xinliang
> David Li via llvm-dev
> *Sent:* Friday, October 27, 2017 11:11 AM
> *To:* David Chisnall
> *Cc:* llvm-dev
> *Subject:* Re: [llvm-dev] RFC: We need to explicitly state that some
> functions are reserved by LLVM
>
>
>
>
>
>
>
> On Fri, Oct 27, 2017 at 1:50 AM, David Chisnall via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> 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.
>
> 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?
>
>
>
>
>
> 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.
>
>
>
> David
>
>
>
>
>
> 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.
>
>
>
>
>
>
>
> David
>
>
> > On 27 Oct 2017, at 04:14, Chandler Carruth via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > I've gotten a fantastic bug report. Consider the LLVM IR:
> >
> > target triple = "x86_64-unknown-linux-gnu"
> >
> > define internal i8* @access({ i8* }* %arg, i64) {
> >   ret i8* undef
> > }
> >
> > define i8* @g({ i8* }* %arg) {
> > bb:
> >   %tmp = alloca { i8* }*, align 8
> >   store { i8* }* %arg, { i8* }** %tmp, align 8
> >   br i1 undef, label %bb4, label %bb1
> >
> > bb1:
> >   %tmp2 = load { i8* }*, { i8* }** %tmp, align 8
> >   %tmp3 = call i8* @access({ i8* }* %tmp2, i64 undef)
> >   br label %bb4
> >
> > bb4:
> >   ret i8* undef
> > }
> >
> > This IR, if compiled with `opt -passes='cgscc(inline,argpromotion)'
> -disable-output` hits a bunch of asserts in the LazyCallGraph.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > So what do we do?
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > There is no need to auto-upgrade here, because again, LLVM's handling
> will remain conservatively correct.
> >
> > 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.
> >
> >
> > 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.
> >
> >
> > Thanks,
> > -Chandler
> >
>
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171027/57112e68/attachment.html>