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

On Tue, Jun 7, 2016 at 1:57 PM, Ryan Taylor <ryta1203 at gmail.com>
wrote:
> Tim,
>
> Currently, I have to do multiple things:
>
> 1) create some setLibcallNames in XXXISelLowering.cpp to generate correct
> naming for RTLIBS.
> 2) lower ISD down to an RTLIB for some calls (and then do solution 1 on
> those to get correct names)
These solve a related but different - CodeGen - problem.

RTLIB libcalls are used when we're not able to select some IR
instruction/intrinsic so have to rely on a runtime library helper
function (e.g., the stuff in compiler-rt/lib/builtins/).

So, #1 and #2 would make LLVM able to emit calls to __xxx_acos when
it sees "@llvm.acos.f32", but it won't let LLVM optimize (constant
fold, transform into the intrinsic, ...) "__xx_acos()" when it sees
it.

It sounds like you also want to recognize and optimize these calls.
That involves (pre-CodeGen) IR-level optimizations.
No, I don't think that's supported today without changing LLVM (see
the list in my first email).
> 3) change TargetLibraryInfo for functions that aren't covered in
solutions 1
> and 2 (so that they can also be optimized)
>
> I must be missing something, I'm just not sure what it is.
>
> Thanks,
>
> Ryan
>
>
> On Tue, Jun 7, 2016 at 4:45 PM, Ryan Taylor <ryta1203 at gmail.com>
wrote:
>>
>> 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?
I agree the name "Target" is a bit awkward, but it's not generic
in
that it behaves differently depending on the target triple, which is
usually not OK in a "generic" analysis.

If you look in TargetLibraryInfo.cpp, there are various checks for
function availability, usually predicated on OS versions.

-Ahmed
>>> 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.
>>
>>
>

Correct, it does check based on OS and triple, what I meant was that it
might be better to have this info in the target specific files and have the
LibraryInfo do a look up of that (like most other sections of the core code
do, ie have the tablegen or ISelLowering specify the libs etc..)

I'm not sure I follow about the RTLIB, I'm able to use an intrinsic for
floor (def int_floor::Intrinsic in IntrinsicsXXX.td) and still use RTLIB to
generate the appropriate name for the function (ie __xxx_floor). It sounds
like you're implying either/or, not both?

I agree, it doesn't seem supported. It looks like I might just need to
change 'TLI.has' and 'TLI.getName' in order to make this happen
(potentially removing the prefix here). This goes back to my first point,
the TLI should be changed to simply get this info generically from the
target information, you seem to agree with that.

Thanks,

Ryan

On Tue, Jun 7, 2016 at 7:06 PM, Ahmed Bougacha <ahmed.bougacha at
gmail.com>
wrote:
> On Tue, Jun 7, 2016 at 1:57 PM, Ryan Taylor <ryta1203 at gmail.com>
wrote:
> > Tim,
> >
> > Currently, I have to do multiple things:
> >
> > 1) create some setLibcallNames in XXXISelLowering.cpp to generate
correct
> > naming for RTLIBS.
> > 2) lower ISD down to an RTLIB for some calls (and then do solution 1
on
> > those to get correct names)
>
> These solve a related but different - CodeGen - problem.
>
> RTLIB libcalls are used when we're not able to select some IR
> instruction/intrinsic so have to rely on a runtime library helper
> function (e.g., the stuff in compiler-rt/lib/builtins/).
>
> So, #1 and #2 would make LLVM able to emit calls to __xxx_acos when
> it sees "@llvm.acos.f32", but it won't let LLVM optimize
(constant
> fold, transform into the intrinsic, ...) "__xx_acos()" when it
sees
> it.
>
> It sounds like you also want to recognize and optimize these calls.
> That involves (pre-CodeGen) IR-level optimizations.
> No, I don't think that's supported today without changing LLVM (see
> the list in my first email).
>
> > 3) change TargetLibraryInfo for functions that aren't covered in
> solutions 1
> > and 2 (so that they can also be optimized)
> >
> > I must be missing something, I'm just not sure what it is.
> >
> > Thanks,
> >
> > Ryan
> >
> >
> > On Tue, Jun 7, 2016 at 4:45 PM, Ryan Taylor <ryta1203 at
gmail.com> wrote:
> >>
> >> 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?
>
> I agree the name "Target" is a bit awkward, but it's not
generic in
> that it behaves differently depending on the target triple, which is
> usually not OK in a "generic" analysis.
>
> If you look in TargetLibraryInfo.cpp, there are various checks for
> function availability, usually predicated on OS versions.
>
> -Ahmed
>
> >>> 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/20160608/d62fa9f9/attachment.html>

On Wed, Jun 8, 2016 at 10:43 AM, Ryan Taylor <ryta1203 at gmail.com>
wrote:
> Correct, it does check based on OS and triple, what I meant was that it
> might be better to have this info in the target specific files and have the
> LibraryInfo do a look up of that (like most other sections of the core code
> do, ie have the tablegen or ISelLowering specify the libs etc..)
I agree it's not the best place, but one difference is that
TargetLibraryInfo is much more about OSes than architectures.
> I'm not sure I follow about the RTLIB, I'm able to use an intrinsic
for
> floor (def int_floor::Intrinsic in IntrinsicsXXX.td) and still use RTLIB to
> generate the appropriate name for the function (ie __xxx_floor). It sounds
> like you're implying either/or, not both?
No, I'm just saying that RTLIB only solves the codegen problem; you'll
need something else (like your intrinsic?) to have better IR
optimizations.
> I agree, it doesn't seem supported. It looks like I might just need to
> change 'TLI.has' and 'TLI.getName' in order to make this
happen (potentially
> removing the prefix here). This goes back to my first point, the TLI should
> be changed to simply get this info generically from the target information,
> you seem to agree with that.
Hmm, what are you really trying to do?  If you want LLVM to recognize
your __xxx functions: yes, the cleanest solution is probably to teach
TLI and its users to recognize the "custom" names, and mark the
functions as available with your custom __xxx names.

HTH,
-Ahmed
> Thanks,
>
> Ryan
>
> On Tue, Jun 7, 2016 at 7:06 PM, Ahmed Bougacha <ahmed.bougacha at
gmail.com>
> wrote:
>>
>> On Tue, Jun 7, 2016 at 1:57 PM, Ryan Taylor <ryta1203 at
gmail.com> wrote:
>> > Tim,
>> >
>> > Currently, I have to do multiple things:
>> >
>> > 1) create some setLibcallNames in XXXISelLowering.cpp to generate
>> > correct
>> > naming for RTLIBS.
>> > 2) lower ISD down to an RTLIB for some calls (and then do solution
1 on
>> > those to get correct names)
>>
>> These solve a related but different - CodeGen - problem.
>>
>> RTLIB libcalls are used when we're not able to select some IR
>> instruction/intrinsic so have to rely on a runtime library helper
>> function (e.g., the stuff in compiler-rt/lib/builtins/).
>>
>> So, #1 and #2 would make LLVM able to emit calls to __xxx_acos when
>> it sees "@llvm.acos.f32", but it won't let LLVM optimize
(constant
>> fold, transform into the intrinsic, ...) "__xx_acos()" when
it sees
>> it.
>>
>> It sounds like you also want to recognize and optimize these calls.
>> That involves (pre-CodeGen) IR-level optimizations.
>> No, I don't think that's supported today without changing LLVM
(see
>> the list in my first email).
>>
>> > 3) change TargetLibraryInfo for functions that aren't covered
in
>> > solutions 1
>> > and 2 (so that they can also be optimized)
>> >
>> > I must be missing something, I'm just not sure what it is.
>> >
>> > Thanks,
>> >
>> > Ryan
>> >
>> >
>> > On Tue, Jun 7, 2016 at 4:45 PM, Ryan Taylor <ryta1203 at
gmail.com> wrote:
>> >>
>> >> 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?
>>
>> I agree the name "Target" is a bit awkward, but it's not
generic in
>> that it behaves differently depending on the target triple, which is
>> usually not OK in a "generic" analysis.
>>
>> If you look in TargetLibraryInfo.cpp, there are various checks for
>> function availability, usually predicated on OS versions.
>>
>> -Ahmed
>>
>> >>> 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.
>> >>
>> >>
>> >
>
>

I'm still not sure why copysign and fabs have to be lowered to a call when
they are represented as a call in the IR?

Looks like the DAG makes them into SDNodes.


On Thu, Jun 9, 2016 at 2:35 PM, Ahmed Bougacha <ahmed.bougacha at
gmail.com>
wrote:
> On Thu, Jun 9, 2016 at 11:28 AM, Ryan Taylor <ryta1203 at gmail.com>
wrote:
> > I'm assuming that "__builtin_" is a keyword in LLVM. If
I have code like:
> >
> > #define acos __builtin_acos
> >
> > extern double acos(double, double);
> >
> > double a;
> > void foo(float b) {
> >   a = acos(b);
> > }
> >
> > I never see a call to "__builtin_acos", is LLVM removing the
prefix
> > __builtin_ ?
>
> Oh, that's a clang thing, not LLVM:  yes, I think clang has special
> handling for __builtin_*, and for libm functions, just turns them into
> a regular function call to the function.  That happens in clang
> CGBuiltin.cpp, getBuiltinLibFunction.
>
> By the time LLVM sees the call, yes, it's just a call to
"@acos".
> There's no such thing as "__builtin_" from LLVM's
standpoint, it's
> purely a C thing.
>
> -Ahmed
>
> > Thanks,
> >
> > Ryan
> >
> > On Thu, Jun 9, 2016 at 2:10 PM, Ahmed Bougacha <ahmed.bougacha at
gmail.com
> >
> > wrote:
> >>
> >> On Wed, Jun 8, 2016 at 10:43 AM, Ryan Taylor <ryta1203 at
gmail.com>
> wrote:
> >> > Correct, it does check based on OS and triple, what I meant
was that
> it
> >> > might be better to have this info in the target specific
files and
> have
> >> > the
> >> > LibraryInfo do a look up of that (like most other sections of
the core
> >> > code
> >> > do, ie have the tablegen or ISelLowering specify the libs
etc..)
> >>
> >> I agree it's not the best place, but one difference is that
> >> TargetLibraryInfo is much more about OSes than architectures.
> >>
> >> > I'm not sure I follow about the RTLIB, I'm able to
use an intrinsic
> for
> >> > floor (def int_floor::Intrinsic in IntrinsicsXXX.td) and
still use
> RTLIB
> >> > to
> >> > generate the appropriate name for the function (ie
__xxx_floor). It
> >> > sounds
> >> > like you're implying either/or, not both?
> >>
> >> No, I'm just saying that RTLIB only solves the codegen
problem; you'll
> >> need something else (like your intrinsic?) to have better IR
> >> optimizations.
> >>
> >> > I agree, it doesn't seem supported. It looks like I might
just need to
> >> > change 'TLI.has' and 'TLI.getName' in order
to make this happen
> >> > (potentially
> >> > removing the prefix here). This goes back to my first point,
the TLI
> >> > should
> >> > be changed to simply get this info generically from the
target
> >> > information,
> >> > you seem to agree with that.
> >>
> >> Hmm, what are you really trying to do?  If you want LLVM to
recognize
> >> your __xxx functions: yes, the cleanest solution is probably to
teach
> >> TLI and its users to recognize the "custom" names, and
mark the
> >> functions as available with your custom __xxx names.
> >>
> >> HTH,
> >> -Ahmed
> >>
> >> > Thanks,
> >> >
> >> > Ryan
> >> >
> >> > On Tue, Jun 7, 2016 at 7:06 PM, Ahmed Bougacha
> >> > <ahmed.bougacha at gmail.com>
> >> > wrote:
> >> >>
> >> >> On Tue, Jun 7, 2016 at 1:57 PM, Ryan Taylor <ryta1203
at gmail.com>
> wrote:
> >> >> > Tim,
> >> >> >
> >> >> > Currently, I have to do multiple things:
> >> >> >
> >> >> > 1) create some setLibcallNames in
XXXISelLowering.cpp to generate
> >> >> > correct
> >> >> > naming for RTLIBS.
> >> >> > 2) lower ISD down to an RTLIB for some calls (and
then do solution
> 1
> >> >> > on
> >> >> > those to get correct names)
> >> >>
> >> >> These solve a related but different - CodeGen - problem.
> >> >>
> >> >> RTLIB libcalls are used when we're not able to select
some IR
> >> >> instruction/intrinsic so have to rely on a runtime
library helper
> >> >> function (e.g., the stuff in compiler-rt/lib/builtins/).
> >> >>
> >> >> So, #1 and #2 would make LLVM able to emit calls to
__xxx_acos when
> >> >> it sees "@llvm.acos.f32", but it won't let
LLVM optimize (constant
> >> >> fold, transform into the intrinsic, ...)
"__xx_acos()" when it sees
> >> >> it.
> >> >>
> >> >> It sounds like you also want to recognize and optimize
these calls.
> >> >> That involves (pre-CodeGen) IR-level optimizations.
> >> >> No, I don't think that's supported today without
changing LLVM (see
> >> >> the list in my first email).
> >> >>
> >> >> > 3) change TargetLibraryInfo for functions that
aren't covered in
> >> >> > solutions 1
> >> >> > and 2 (so that they can also be optimized)
> >> >> >
> >> >> > I must be missing something, I'm just not sure
what it is.
> >> >> >
> >> >> > Thanks,
> >> >> >
> >> >> > Ryan
> >> >> >
> >> >> >
> >> >> > On Tue, Jun 7, 2016 at 4:45 PM, Ryan Taylor
<ryta1203 at gmail.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> 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?
> >> >>
> >> >> I agree the name "Target" is a bit awkward, but
it's not generic in
> >> >> that it behaves differently depending on the target
triple, which is
> >> >> usually not OK in a "generic" analysis.
> >> >>
> >> >> If you look in TargetLibraryInfo.cpp, there are various
checks for
> >> >> function availability, usually predicated on OS versions.
> >> >>
> >> >> -Ahmed
> >> >>
> >> >> >>> 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/20160614/db85663a/attachment.html>

If I do

T.getArch() == xxx
   TLI.setUnavailable(LibFunc::copysign)

then this works at generating a call instead of not being able to select
the ISD::FCOPYSIGN, but I don't know why I don't need to do this for
other
LibFunc functions (such as floor, etc... these generate call just fine)?

Thanks,
Ryan



On Tue, Jun 14, 2016 at 11:58 AM, Ryan Taylor <ryta1203 at gmail.com>
wrote:
> I'm still not sure why copysign and fabs have to be lowered to a call
when
> they are represented as a call in the IR?
>
> Looks like the DAG makes them into SDNodes.
>
>
> On Thu, Jun 9, 2016 at 2:35 PM, Ahmed Bougacha <ahmed.bougacha at
gmail.com>
> wrote:
>
>> On Thu, Jun 9, 2016 at 11:28 AM, Ryan Taylor <ryta1203 at
gmail.com> wrote:
>> > I'm assuming that "__builtin_" is a keyword in LLVM.
If I have code
>> like:
>> >
>> > #define acos __builtin_acos
>> >
>> > extern double acos(double, double);
>> >
>> > double a;
>> > void foo(float b) {
>> >   a = acos(b);
>> > }
>> >
>> > I never see a call to "__builtin_acos", is LLVM removing
the prefix
>> > __builtin_ ?
>>
>> Oh, that's a clang thing, not LLVM:  yes, I think clang has special
>> handling for __builtin_*, and for libm functions, just turns them into
>> a regular function call to the function.  That happens in clang
>> CGBuiltin.cpp, getBuiltinLibFunction.
>>
>> By the time LLVM sees the call, yes, it's just a call to
"@acos".
>> There's no such thing as "__builtin_" from LLVM's
standpoint, it's
>> purely a C thing.
>>
>> -Ahmed
>>
>> > Thanks,
>> >
>> > Ryan
>> >
>> > On Thu, Jun 9, 2016 at 2:10 PM, Ahmed Bougacha <
>> ahmed.bougacha at gmail.com>
>> > wrote:
>> >>
>> >> On Wed, Jun 8, 2016 at 10:43 AM, Ryan Taylor <ryta1203 at
gmail.com>
>> wrote:
>> >> > Correct, it does check based on OS and triple, what I
meant was that
>> it
>> >> > might be better to have this info in the target specific
files and
>> have
>> >> > the
>> >> > LibraryInfo do a look up of that (like most other
sections of the
>> core
>> >> > code
>> >> > do, ie have the tablegen or ISelLowering specify the libs
etc..)
>> >>
>> >> I agree it's not the best place, but one difference is
that
>> >> TargetLibraryInfo is much more about OSes than architectures.
>> >>
>> >> > I'm not sure I follow about the RTLIB, I'm able
to use an intrinsic
>> for
>> >> > floor (def int_floor::Intrinsic in IntrinsicsXXX.td) and
still use
>> RTLIB
>> >> > to
>> >> > generate the appropriate name for the function (ie
__xxx_floor). It
>> >> > sounds
>> >> > like you're implying either/or, not both?
>> >>
>> >> No, I'm just saying that RTLIB only solves the codegen
problem; you'll
>> >> need something else (like your intrinsic?) to have better IR
>> >> optimizations.
>> >>
>> >> > I agree, it doesn't seem supported. It looks like I
might just need
>> to
>> >> > change 'TLI.has' and 'TLI.getName' in
order to make this happen
>> >> > (potentially
>> >> > removing the prefix here). This goes back to my first
point, the TLI
>> >> > should
>> >> > be changed to simply get this info generically from the
target
>> >> > information,
>> >> > you seem to agree with that.
>> >>
>> >> Hmm, what are you really trying to do?  If you want LLVM to
recognize
>> >> your __xxx functions: yes, the cleanest solution is probably
to teach
>> >> TLI and its users to recognize the "custom" names,
and mark the
>> >> functions as available with your custom __xxx names.
>> >>
>> >> HTH,
>> >> -Ahmed
>> >>
>> >> > Thanks,
>> >> >
>> >> > Ryan
>> >> >
>> >> > On Tue, Jun 7, 2016 at 7:06 PM, Ahmed Bougacha
>> >> > <ahmed.bougacha at gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> On Tue, Jun 7, 2016 at 1:57 PM, Ryan Taylor
<ryta1203 at gmail.com>
>> wrote:
>> >> >> > Tim,
>> >> >> >
>> >> >> > Currently, I have to do multiple things:
>> >> >> >
>> >> >> > 1) create some setLibcallNames in
XXXISelLowering.cpp to generate
>> >> >> > correct
>> >> >> > naming for RTLIBS.
>> >> >> > 2) lower ISD down to an RTLIB for some calls
(and then do
>> solution 1
>> >> >> > on
>> >> >> > those to get correct names)
>> >> >>
>> >> >> These solve a related but different - CodeGen -
problem.
>> >> >>
>> >> >> RTLIB libcalls are used when we're not able to
select some IR
>> >> >> instruction/intrinsic so have to rely on a runtime
library helper
>> >> >> function (e.g., the stuff in
compiler-rt/lib/builtins/).
>> >> >>
>> >> >> So, #1 and #2 would make LLVM able to emit calls to
__xxx_acos when
>> >> >> it sees "@llvm.acos.f32", but it won't
let LLVM optimize (constant
>> >> >> fold, transform into the intrinsic, ...)
"__xx_acos()" when it sees
>> >> >> it.
>> >> >>
>> >> >> It sounds like you also want to recognize and
optimize these calls.
>> >> >> That involves (pre-CodeGen) IR-level optimizations.
>> >> >> No, I don't think that's supported today
without changing LLVM (see
>> >> >> the list in my first email).
>> >> >>
>> >> >> > 3) change TargetLibraryInfo for functions that
aren't covered in
>> >> >> > solutions 1
>> >> >> > and 2 (so that they can also be optimized)
>> >> >> >
>> >> >> > I must be missing something, I'm just not
sure what it is.
>> >> >> >
>> >> >> > Thanks,
>> >> >> >
>> >> >> > Ryan
>> >> >> >
>> >> >> >
>> >> >> > On Tue, Jun 7, 2016 at 4:45 PM, Ryan Taylor
<ryta1203 at gmail.com>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> 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?
>> >> >>
>> >> >> I agree the name "Target" is a bit awkward,
but it's not generic in
>> >> >> that it behaves differently depending on the target
triple, which is
>> >> >> usually not OK in a "generic" analysis.
>> >> >>
>> >> >> If you look in TargetLibraryInfo.cpp, there are
various checks for
>> >> >> function availability, usually predicated on OS
versions.
>> >> >>
>> >> >> -Ahmed
>> >> >>
>> >> >> >>> 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/20160614/76c051ea/attachment-0001.html>