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

[Ahmed Bougacha via llvm-dev]

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