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

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>

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)
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?
>>
>> 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/e2b0f034/attachment.html>

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