search for: sincosf

...128, nullptr); setLibcallName(RTLIB::SRL_I128, nullptr); setLibcallName(RTLIB::SRA_I128, nullptr); + setLibcallName(RTLIB::MUL_I128, nullptr); } // Combine sin / cos into one node or libcall if possible. if (Subtarget.hasSinCos()) { setLibcallName(RTLIB::SINCOS_F32, "sincosf"); This will make the Legalizer choose the brute force approach below: void DAGTypeLegalizer::ExpandIntRes_MUL(SDNode *N, SDValue &Lo, SDValue &Hi) { ... if (LC == RTLIB::UNKNOWN_LIBCALL || !TLI.getLibcallName(LC)) { // We'll expand...

Hi, I'm looking at http://llvm.org/bugs/show_bug.cgi?id=13204 which involves converting calls to sin and cos to sincos (when available) Initially I thought about transforming calls to sinf/cosf to sincosf. However, I don't think this is a legal transformation given that a declaration for a function called sinf is not necessarily the standard library function. Therefore it makes sense to transform intrinsic calls to sin and cos. One problem with this is that clang does not generate sin/cos intri...

On 22/01/13 05:30, Redmond, Paul wrote: [...] > I'm looking at http://llvm.org/bugs/show_bug.cgi?id=13204 which involves converting calls to sin and cos to sincos (when available) > > Initially I thought about transforming calls to sinf/cosf to sincosf. However, I don't think this is a legal transformation given that a declaration for a function called sinf is not necessarily the standard library function. I've actually just dealt with this --- standard library calls, including sinf, *are* promoted to intrinsics if the compiler sees them...

Looks like I have run into the same issue reported in: https://bugs.llvm.org/show_bug.cgi?id=20871 Is there a fix or work-around for it? The bug report seems to be still open. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171005/46c1282d/attachment.html>

Dear testers, Start your engines; 6.0.0-rc1 was just tagged. I know there are still open blockers and it's early in the process in a way, but I'd like to find out where we are. Please run the test script, let me know the results, and upload binaries. Thanks, Hans

...em, which > are the same > as Diana recorded in PR35997. > > On my big endian MIPS system, I'm also seeing PR35997 and: > > PR36056: lld test failures. > > MemorySanitizer-MIPS64 :: chained_origin.cc > MemorySanitizer-Unit :: ./Msan-mips64-Test/MemorySanitizer.sincosf > SanitizerCommon-tsan-mips64-Linux :: Posix/dedup_token_length_test.cc > > A patch has been committed to trunk for the tsan failure (PR36059 for the > merge request), and I'm investigating the msan failures. > > I also hit an issue compiling the test suite: PR36058, patch...