[llvm-dev] llvm intrinsics/libc/libm question

[Ryan Taylor via llvm-dev]

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>