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

[Ahmed Bougacha via llvm-dev]

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