<div dir="ltr"><div>Tim,</div><div><br></div><div>Currently, I have to do multiple things:</div><div><br></div><div>1) create some setLibcallNames in XXXISelLowering.cpp to generate correct naming for RTLIBS.</div><div>2) lower ISD down to an RTLIB for some calls (and then do solution 1 on those to get correct names)</div><div>3) change TargetLibraryInfo for functions that aren't covered in solutions 1 and 2 (so that they can also be optimized)</div><div><br></div><div>I must be missing something, I'm just not sure what it is.</div><div><br></div><div>Thanks,</div><div><br></div><div>Ryan</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 7, 2016 at 4:45 PM, Ryan Taylor <span dir="ltr"><<a href="mailto:ryta1203@gmail.com" target="_blank">ryta1203@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Tim,</div><div><br></div><div> 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.</div><div><br></div><div> 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.</div><div><br></div><div> 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.</div><div><br>Thanks,</div><div><br></div><div>Ryan</div><div><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 7, 2016 at 4:38 PM, Tim Northover <span dir="ltr"><<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 7 June 2016 at 13:24, Ryan Taylor via llvm-dev<br>
<span><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> Not sure why it's called TargetLibraryInfo if it's not in target specific<br>
> code? It seems that ALL targets use this code, making it generic. Am I<br>
> missing something here?<br>
<br>
</span>Some of the names can vary by platform, for example ARM sometimes has<br>
__aeabi_memcpy instead of memcpy<br>
<span><br>
> ps. The spec also states (albeit unclearly) that you can use "#undef" to<br>
> omit a library function so that a user defined function of the same name can<br>
> be used but LLVM doesn't seem to support that.<br>
<br>
</span>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>
<span><font color="#888888"><br>
Tim.<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>