[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