<div dir="ltr"><div>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..)</div><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>Thanks,</div><div><br></div><div>Ryan</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 7, 2016 at 7:06 PM, Ahmed Bougacha <span dir="ltr"><<a href="mailto:ahmed.bougacha@gmail.com" target="_blank">ahmed.bougacha@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Tue, Jun 7, 2016 at 1:57 PM, Ryan Taylor <<a href="mailto:ryta1203@gmail.com">ryta1203@gmail.com</a>> wrote:<br>
> Tim,<br>
><br>
</span><span>> Currently, I have to do multiple things:<br>
><br>
> 1) create some setLibcallNames in XXXISelLowering.cpp to generate correct<br>
> naming for RTLIBS.<br>
> 2) lower ISD down to an RTLIB for some calls (and then do solution 1 on<br>
> those to get correct names)<br>
<br>
</span>These solve a related but different - CodeGen - problem.<br>
<br>
RTLIB libcalls are used when we're not able to select some IR<br>
instruction/intrinsic so have to rely on a runtime library helper<br>
function (e.g., the stuff in compiler-rt/lib/builtins/).<br>
<br>
So, #1 and #2 would make LLVM able to emit calls to __xxx_acos when<br>
it sees "@llvm.acos.f32", but it won't let LLVM optimize (constant<br>
fold, transform into the intrinsic, ...) "__xx_acos()" when it sees<br>
it.<br>
<br>
It sounds like you also want to recognize and optimize these calls.<br>
That involves (pre-CodeGen) IR-level optimizations.<br>
No, I don't think that's supported today without changing LLVM (see<br>
the list in my first email).<br>
<div><div class="h5"><br>
> 3) change TargetLibraryInfo for functions that aren't covered in solutions 1<br>
> and 2 (so that they can also be optimized)<br>
><br>
> I must be missing something, I'm just not sure what it is.<br>
><br>
> Thanks,<br>
><br>
> Ryan<br>
><br>
><br>
> On Tue, Jun 7, 2016 at 4:45 PM, Ryan Taylor <<a href="mailto:ryta1203@gmail.com">ryta1203@gmail.com</a>> wrote:<br>
>><br>
>> Tim,<br>
>><br>
>>  Are you referring to setLibcallName? That is target specific yes but<br>
>> there isn't RTLIB for most of the libm functions, for example, for acos this<br>
>> doesn't apply.<br>
>><br>
>>  Ideally what I would like is to create a libc with functions like acos<br>
>> called something like __xxx_acos that can still be recognized to be<br>
>> optimized.<br>
>><br>
>>  RTLIB is pretty limited but it works fine, I can just use<br>
>> setLibcallName(RTLIB::floor, "__xxx_floor")... but again, the functions that<br>
>> are RTLIB are limited. Using intrinsics make it more difficult because then<br>
>> you have to match the intrinsic (rather than it automatically generating a<br>
>> lib call). ISD is just as bad (FCOPYSIGN, FABS for example) because then<br>
>> they need to be manually lowered.<br>
>> Thanks,<br>
>><br>
>> Ryan<br>
>><br>
>><br>
>><br>
>> On Tue, Jun 7, 2016 at 4:38 PM, Tim Northover <<a href="mailto:t.p.northover@gmail.com">t.p.northover@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> On 7 June 2016 at 13:24, Ryan Taylor via llvm-dev<br>
>>> <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>>> > Not sure why it's called TargetLibraryInfo if it's not in target<br>
>>> > specific<br>
>>> > code? It seems that ALL targets use this code, making it generic. Am I<br>
>>> > missing something here?<br>
<br>
</div></div>I agree the name "Target" is a bit awkward, but it's not generic in<br>
that it behaves differently depending on the target triple, which is<br>
usually not OK in a "generic" analysis.<br>
<br>
If you look in TargetLibraryInfo.cpp, there are various checks for<br>
function availability, usually predicated on OS versions.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Ahmed<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
>>> Some of the names can vary by platform, for example ARM sometimes has<br>
>>> __aeabi_memcpy instead of memcpy<br>
>>><br>
>>> > ps. The spec also states (albeit unclearly) that you can use "#undef"<br>
>>> > to<br>
>>> > omit a library function so that a user defined function of the same<br>
>>> > name can<br>
>>> > be used but LLVM doesn't seem to support that.<br>
>>><br>
>>> I think it says exactly the opposite: (7.1.2p3):<br>
>>><br>
>>>     "If the program removes (with #undef) any macro definition of an<br>
>>> identifier in the first group listed above, the behavior is<br>
>>> undefined."<br>
>>><br>
>>> Incidentally, I don't think anyone's mentioned that "-ffreestanding"<br>
>>> will probably inhibit the intrinsics substantially if that's what<br>
>>> you're after (technically, it's probably a compiler extension that it<br>
>>> gives them back to the user, but everyone does it as far as I know).<br>
>>><br>
>>> Cheers.<br>
>>><br>
>>> Tim.<br>
>><br>
>><br>
><br>
</div></div></blockquote></div><br></div>