[llvm-dev] llvm intrinsics/libc/libm question
Ryan Taylor via llvm-dev
llvm-dev at lists.llvm.org
Tue Jun 7 13:45:46 PDT 2016
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
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
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.
On Tue, Jun 7, 2016 at 4:38 PM, Tim Northover <t.p.northover at gmail.com>
> 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
> > 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
> 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).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev