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

Hal Finkel via llvm-dev llvm-dev at lists.llvm.org
Fri Oct 27 11:48:20 PDT 2017


On 10/27/2017 01:27 PM, David Majnemer via llvm-dev wrote:
> 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.

I think that's what's being proposed. nobuiltin does not follow our 
general conventions in this regard, whereas this new thing would.

  -Hal

>
> On Fri, Oct 27, 2017 at 11:15 AM, Robinson, Paul via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto: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
>     <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
>         <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
>         <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
>     <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

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171027/c62232e6/attachment-0001.html>


More information about the llvm-dev mailing list