llvm dev - Jun 2016 - llvm intrinsics/libc/libm question

In the first code I see a 'tail call @acos', in the second code I see a
tail call @llvm.acos.f32'. (sorry, there should be only one input for acos,
I've been trying many libm/libc functions).

Not sure why it's called TargetLibraryInfo if it's not in target
specific
code? It seems that ALL targets use this code, making it generic. Am I
missing something here?

Basically you're saying if I changed/added the XXXacos in
TargetLibraryInfo::hasOptimizedCodeGen then the ConstantFolding (and other
opts) could then opt for this libm call?

Thanks,

Ryan

ps. The spec also states (albeit unclearly) that you can use "#undef"
to
omit a library function so that a user defined function of the same name
can be used but LLVM doesn't seem to support that.


On Tue, Jun 7, 2016 at 12:23 PM, Ahmed Bougacha <ahmed.bougacha at
gmail.com>
wrote:
> On Tue, Jun 7, 2016 at 8:03 AM, Ryan Taylor via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > I'm trying to figure out exactly how the intrinsics/libc/libm work
in
> llvm.
>
> Intrinsics are basically "lesser" instructions that aren't
guaranteed
> to have first-class support (e.g., work on all targets). They are
> specified in the LangRef.
>
> Target intrinsics are similar to generic intrinsics, but are
> specifically only available on one target. They are (intentionally
> under-) specified in the various Intrinsics<Target>.td files.
>
> Some functions (libc, libm, and a few others) are recognized as having
> well-defined behavior for the target platform;  this information is in
> TargetLibraryInfo.
>
> > For example, this code return user defined function:
> >
> >
> > float acos(float x, float y)
> > {
> >     return x+y;
> > }
> >
> > float a;
> > void foo(float b, float c)
> > {
> >  a = acos(b, c);
> > }
> >
> >
> > But this code returns llvm.intrinsic:
> >
> >
> > float acos(float, float);
> >
> > float a;
> > void foo(float b, float c)
> > {
> >  a = acos(b, c);
> > }
> >
> > float acos(float x, float y)
> > {
> >  return x+y;
> > }
> >
> > What is the expected behavior here?
>
> I don't see how they can behave differently.  What IR are you seeing?
>
> > Also, there are certain "standard C library functions"
included in LLVM
> that
> > I'd like to remove without modifying core code, is this possible?
>
> If you're using clang: -fno-builtin=acos is what you're looking
for.
>
> If you're using llvm: when setting up your pass pipeline, you should
> create an instance of TargetLibraryInfo (an example is in
> tools/opt/opt.cpp), and either use:
> - setUnavailable(LibFunc::acos): this marks acos as
"unavailable",
> preventing optimizations from making assumptions about its behavior.
> Equivalent to clang -fno-builtin-acos
> - disableAllFunctions(): this marks all known functions as
> unavailable.  Equivalent to clang -fno-builtin
>
> > I'm also curious how LLVM handles pure functions in regards to
> > optimizations. For example, libm functions such as acos.
>
> Note that I don't think libm functions are pure on most platform,
> because they can modify errno (-ffast-math/-fno-math-errno disables
> that, though).
>
> > It appears that X86
> > doesn't have acos as an intrinsic and instead just calls a
function "tail
> > call @acos...", is this still able to be optimized.
>
> Yes, because TLI knows about the name 'acos'.  However, the
prototype
> needs to be reasonably correct ('double @acos(double)'), but
isn't in
> your example.  (Specifically, ConstantFolding checks that @acos only
> has one operand, but yours has two.)
>
> > I see the hardcoded
> > 'name' lookup for 'acos' in ConstantFolding.cpp. It
doesn't appear that
> if
> > you slightly change the name from 'acos' to say
'XXX_acos' in your libm
> > it'll still be optimized?
>
> Correct, it won't be.
>
> It's possible to make that happen with a few patches, but there has
> been no need for that yet:
>
> - replace the various calls to TLI::has() or
> TLI::getLibFunc(StringRef, Func&) with TLI::getLibFunc(Function&,
> Func&).  Any of the former are probably hiding bugs related to
> incorrect prototypes
>
> - teach TLI::getLibFunc to check function availability using the
> custom name instead of always checking the standard name.  Again, this
> is (arguably) hiding bugs, where we recognize the standard name even
> though it's not what the target uses
>
> - fix canConstantFoldCallTo to pass it TLI or maybe remove it entirely
> (it's always used before ConstantFoldCall, which does check TLI)
>
> - tell TLI that 'acos' is available with name 'XXX_acos'
for your target
>
> -Ahmed
>
> > Thanks,
> >
> > Ryan
> >
> > _______________________________________________
> > 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/20160607/a1a612c6/attachment.html>

On 7 June 2016 at 13:24, Ryan Taylor via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Not sure why it's called TargetLibraryInfo if it's not in target
specific
> code? It seems that ALL targets use this code, making it generic. Am I
> missing something here?
Some of the names can vary by platform, for example ARM sometimes has
__aeabi_memcpy instead of memcpy
> ps. The spec also states (albeit unclearly) that you can use
"#undef" to
> omit a library function so that a user defined function of the same name
can
> be used but LLVM doesn't seem to support that.
I think it says exactly the opposite: (7.1.2p3):

    "If the program removes (with #undef) any macro definition of an
identifier in the first group listed above, the behavior is
undefined."

Incidentally, I don't think anyone's mentioned that
"-ffreestanding"
will probably inhibit the intrinsics substantially if that's what
you're after (technically, it's probably a compiler extension that it
gives them back to the user, but everyone does it as far as I know).

Cheers.

Tim.

Tim,

 Are you referring to setLibcallName? That is target specific yes but there
isn't RTLIB for most of the libm functions, for example, for acos this
doesn't apply.

 Ideally what I would like is to create a libc with functions like acos
called something like __xxx_acos that can still be recognized to be
optimized.

 RTLIB is pretty limited but it works fine, I can just use
setLibcallName(RTLIB::floor, "__xxx_floor")... but again, the
functions
that are RTLIB are limited. Using intrinsics make it more difficult because
then you have to match the intrinsic (rather than it automatically
generating a lib call). ISD is just as bad (FCOPYSIGN, FABS for example)
because then they need to be manually lowered.

Thanks,

Ryan



On Tue, Jun 7, 2016 at 4:38 PM, Tim Northover <t.p.northover at gmail.com>
wrote:
> On 7 June 2016 at 13:24, Ryan Taylor via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > Not sure why it's called TargetLibraryInfo if it's not in
target specific
> > code? It seems that ALL targets use this code, making it generic. Am I
> > missing something here?
>
> Some of the names can vary by platform, for example ARM sometimes has
> __aeabi_memcpy instead of memcpy
>
> > ps. The spec also states (albeit unclearly) that you can use
"#undef" to
> > omit a library function so that a user defined function of the same
name
> can
> > be used but LLVM doesn't seem to support that.
>
> I think it says exactly the opposite: (7.1.2p3):
>
>     "If the program removes (with #undef) any macro definition of an
> identifier in the first group listed above, the behavior is
> undefined."
>
> Incidentally, I don't think anyone's mentioned that
"-ffreestanding"
> will probably inhibit the intrinsics substantially if that's what
> you're after (technically, it's probably a compiler extension that
it
> gives them back to the user, but everyone does it as far as I know).
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160607/a049c3ff/attachment.html>

per 7.1.4p1:

 The use of #undef to remove any macro definition will also ensure that an
actual function is referred to

And then footnote 187:

Because external identifiers and some macro names beginning with an
underscore are reserved, implementations may provide special semantics for
such names. For example, the identifier _BUILTIN_abs could be used to
indicate generation of in-line code for the abs function. Thus, the
appropriate header could specify:

#define abs(x) __builtin_abs(x)

for a compiler whose code generator will accept it.

In this manner, a user desiring to guarantee that a given library function
such as abs will be a genuine function may write

#undef abs

whether the implementation’s header provides a macro implementation of abs
or a built-in implementation. The prototype for the function, which
precedes and is hidden by any macro definition, is thereby revealed also.


On Tue, Jun 7, 2016 at 4:38 PM, Tim Northover <t.p.northover at gmail.com>
wrote:
> On 7 June 2016 at 13:24, Ryan Taylor via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > Not sure why it's called TargetLibraryInfo if it's not in
target specific
> > code? It seems that ALL targets use this code, making it generic. Am I
> > missing something here?
>
> Some of the names can vary by platform, for example ARM sometimes has
> __aeabi_memcpy instead of memcpy
>
> > ps. The spec also states (albeit unclearly) that you can use
"#undef" to
> > omit a library function so that a user defined function of the same
name
> can
> > be used but LLVM doesn't seem to support that.
>
> I think it says exactly the opposite: (7.1.2p3):
>
>     "If the program removes (with #undef) any macro definition of an
> identifier in the first group listed above, the behavior is
> undefined."
>
> Incidentally, I don't think anyone's mentioned that
"-ffreestanding"
> will probably inhibit the intrinsics substantially if that's what
> you're after (technically, it's probably a compiler extension that
it
> gives them back to the user, but everyone does it as far as I know).
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160607/1fde4fbc/attachment.html>