This is an archive of the discontinued LLVM Phabricator instance.

Limit sincos to Linux
Needs RevisionPublic

Authored by andrew on Jan 11 2017, 10:14 AM.

Details

Summary

FreeBSD doesn't have sincos, and as far as I can tell nether do the other BSDs. As such restrict the calls to this to just Linux.

Diff Detail

Repository
rL LLVM

Event Timeline

andrew updated this revision to Diff 83996.Jan 11 2017, 10:14 AM
andrew retitled this revision from to Limit sincos to Linux.
andrew updated this object.
andrew set the repository for this revision to rL LLVM.
andrew added subscribers: emaste, dim.
emaste added inline comments.Jan 11 2017, 10:17 AM
lib/CodeGen/TargetLoweringBase.cpp
490

Which systems have isGNUEnvironment true?

andrew added inline comments.Jan 11 2017, 10:19 AM
lib/CodeGen/TargetLoweringBase.cpp
490

It seems to be when the triple ends with gnu*

Not part of this change, but it seems unfortunate that we use isGNUEnvironment or isOSLinux here to determine if sincos is available, but then in lib/Target/ARM/ARMSubtarget.cpp:

bool ARMSubtarget::hasSinCos() const {
  return isTargetWatchOS() ||
    (isTargetIOS() && !getTargetTriple().isOSVersionLT(7, 0));
}

and lib/Target/X86/X86ISelLowering.cpp:

bool X86Subtarget::hasSinCos() const {
  return getTargetTriple().isMacOSX() &&
    !getTargetTriple().isMacOSXVersionLT(10, 9) &&
    is64Bit();
}
dim added a comment.Jan 11 2017, 12:13 PM

It looks good to me.

It is strange that both TargetLoweringBase.cpp and the ARM/X86 SubTargets have their own "hasSinCos" logic, though.

rengolin requested changes to this revision.Jan 11 2017, 12:35 PM
rengolin edited edge metadata.

I don't understand this change. I don't expect to see sincos in freebsd even in the old code. If it did, than there was something wrong that wasn't fixed...

I'm also surprised that linux-gnu is not a GNU environment...

Can you dig a bit more the reason for those changes?

Thanks!
--renato

This revision now requires changes to proceed.Jan 11 2017, 12:35 PM

The ARM/X86 hasSinCos seems to be for macOS/iOS/watchOS.

We are getting sincos on FreeBSD on arm because we use armv6-freebsd-gnueabihf so TT.isGNUEnvironment() returns true enabling these functions.

linux-gnu is a gnu environment, however it's missing --enable-unsafe-fp-math which is needed to enable the call to sincos.

rengolin added a comment.EditedJan 12 2017, 11:38 AM

The ARM/X86 hasSinCos seems to be for macOS/iOS/watchOS.

Hum, that sounds wrong. GLIBC has sincos since version 2.1, and if we're using it (whether ARM or x86), we can include it.

We are getting sincos on FreeBSD on arm because we use armv6-freebsd-gnueabihf so TT.isGNUEnvironment() returns true enabling these functions.

Why do you use "gnueabihf" if you don't use GLIBC? Why not just EABIHF, which would *also* work with GLIBC and GCC, but not have the idiosyncrasies of GLIBC.

linux-gnu is a gnu environment, however it's missing --enable-unsafe-fp-math which is needed to enable the call to sincos.

Right. "linux-gnu" is not used with ARM. I know it's not in this patch, but we should change that to "gnueabi" instead.

cheers,
--renato

dim added inline comments.Apr 5 2017, 5:15 AM
lib/CodeGen/TargetLoweringBase.cpp
490

See the code in include/llvm/ADT/Triple.h:

bool isGNUEnvironment() const {
  EnvironmentType Env = getEnvironment();
  return Env == Triple::GNU || Env == Triple::GNUABI64 ||
         Env == Triple::GNUEABI || Env == Triple::GNUEABIHF ||
         Env == Triple::GNUX32;
}

Though maybe a better name for the function would be isGLibCEnvironment() ... :)

rengolin added inline comments.Apr 5 2017, 5:30 AM
lib/CodeGen/TargetLoweringBase.cpp
490

No, other libraries can emulate the GNU environment just as well, and they still need to provide whatever GNU does, or they shouldn't be called "gnuabi".

This just looks like a nomenclature problem. FreeBSD uses "gnuabi" names and don't want to provide "gnuabi" features.

I can see only two solutions:

  1. Short-term: include a " && ! Triple::BSD" or something on isGNUEnvironment with a BIG FIXME line.
  1. Long-term: emulate the full GNU ABI, or stop calling itself "gnueabi".