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

[Ryan Taylor via llvm-dev]

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>