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

Fri Oct 27 11:15:17 PDT 2017

+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<mailto: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<mailto: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<mailto: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<mailto: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/c110639b/attachment-0001.html>