2011-02-19 05:50:34 +08:00
|
|
|
//===-- TargetLibraryInfo.cpp - Runtime library information ----------------==//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file implements the TargetLibraryInfo class.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2015-01-15 10:16:27 +08:00
|
|
|
#include "llvm/Analysis/TargetLibraryInfo.h"
|
2011-02-19 05:50:34 +08:00
|
|
|
#include "llvm/ADT/Triple.h"
|
2017-05-20 06:37:09 +08:00
|
|
|
#include "llvm/IR/Constants.h"
|
2015-03-18 03:50:55 +08:00
|
|
|
#include "llvm/Support/CommandLine.h"
|
2011-02-19 05:50:34 +08:00
|
|
|
using namespace llvm;
|
|
|
|
|
2015-03-18 03:50:55 +08:00
|
|
|
static cl::opt<TargetLibraryInfoImpl::VectorLibrary> ClVectorLibrary(
|
|
|
|
"vector-library", cl::Hidden, cl::desc("Vector functions library"),
|
|
|
|
cl::init(TargetLibraryInfoImpl::NoLibrary),
|
|
|
|
cl::values(clEnumValN(TargetLibraryInfoImpl::NoLibrary, "none",
|
|
|
|
"No vector functions library"),
|
|
|
|
clEnumValN(TargetLibraryInfoImpl::Accelerate, "Accelerate",
|
|
|
|
"Accelerate framework"),
|
2016-07-30 00:42:44 +08:00
|
|
|
clEnumValN(TargetLibraryInfoImpl::SVML, "SVML",
|
2018-11-24 14:41:39 +08:00
|
|
|
"Intel SVML library"),
|
|
|
|
clEnumValN(TargetLibraryInfoImpl::SLEEFGNUABI, "sleefgnuabi",
|
|
|
|
"SIMD Library for Evaluating Elementary Functions")));
|
2015-03-18 03:50:55 +08:00
|
|
|
|
2016-10-01 11:10:48 +08:00
|
|
|
StringRef const TargetLibraryInfoImpl::StandardNames[LibFunc::NumLibFuncs] = {
|
2015-03-04 07:41:58 +08:00
|
|
|
#define TLI_DEFINE_STRING
|
|
|
|
#include "llvm/Analysis/TargetLibraryInfo.def"
|
2015-03-09 00:07:39 +08:00
|
|
|
};
|
2011-11-17 09:27:36 +08:00
|
|
|
|
2013-11-03 14:48:38 +08:00
|
|
|
static bool hasSinCosPiStret(const Triple &T) {
|
|
|
|
// Only Darwin variants have _stret versions of combined trig functions.
|
2014-10-09 13:43:30 +08:00
|
|
|
if (!T.isOSDarwin())
|
2013-11-03 14:48:38 +08:00
|
|
|
return false;
|
|
|
|
|
|
|
|
// The ABI is rather complicated on x86, so don't do anything special there.
|
|
|
|
if (T.getArch() == Triple::x86)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (T.isMacOSX() && T.isMacOSXVersionLT(10, 9))
|
|
|
|
return false;
|
|
|
|
|
2014-10-09 13:43:30 +08:00
|
|
|
if (T.isiOS() && T.isOSVersionLT(7, 0))
|
2013-11-03 14:48:38 +08:00
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2017-12-16 02:54:29 +08:00
|
|
|
/// Initialize the set of available library functions based on the specified
|
|
|
|
/// target triple. This should be carefully written so that a missing target
|
|
|
|
/// triple gets a sane set of defaults.
|
[PM] Rework how the TargetLibraryInfo pass integrates with the new pass
manager to support the actual uses of it. =]
When I ported instcombine to the new pass manager I discover that it
didn't work because TLI wasn't available in the right places. This is
a somewhat surprising and/or subtle aspect of the new pass manager
design that came up before but I think is useful to be reminded of:
While the new pass manager *allows* a function pass to query a module
analysis, it requires that the module analysis is already run and cached
prior to the function pass manager starting up, possibly with
a 'require<foo>' style utility in the pass pipeline. This is an
intentional hurdle because using a module analysis from a function pass
*requires* that the module analysis is run prior to entering the
function pass manager. Otherwise the other functions in the module could
be in who-knows-what state, etc.
A somewhat surprising consequence of this design decision (at least to
me) is that you have to design a function pass that leverages
a module analysis to do so as an optional feature. Even if that means
your function pass does no work in the absence of the module analysis,
you have to handle that possibility and remain conservatively correct.
This is a natural consequence of things being able to invalidate the
module analysis and us being unable to re-run it. And it's a generally
good thing because it lets us reorder passes arbitrarily without
breaking correctness, etc.
This ends up causing problems in one case. What if we have a module
analysis that is *definitionally* impossible to invalidate. In the
places this might come up, the analysis is usually also definitionally
trivial to run even while other transformation passes run on the module,
regardless of the state of anything. And so, it follows that it is
natural to have a hard requirement on such analyses from a function
pass.
It turns out, that TargetLibraryInfo is just such an analysis, and
InstCombine has a hard requirement on it.
The approach I've taken here is to produce an analysis that models this
flexibility by making it both a module and a function analysis. This
exposes the fact that it is in fact safe to compute at any point. We can
even make it a valid CGSCC analysis at some point if that is useful.
However, we don't want to have a copy of the actual target library info
state for each function! This state is specific to the triple. The
somewhat direct and blunt approach here is to turn TLI into a pimpl,
with the state and mutators in the implementation class and the query
routines primarily in the wrapper. Then the analysis can lazily
construct and cache the implementations, keyed on the triple, and
on-demand produce wrappers of them for each function.
One minor annoyance is that we will end up with a wrapper for each
function in the module. While this is a bit wasteful (one pointer per
function) it seems tolerable. And it has the advantage of ensuring that
we pay the absolute minimum synchronization cost to access this
information should we end up with a nice parallel function pass manager
in the future. We could look into trying to mark when analysis results
are especially cheap to recompute and more eagerly GC-ing the cached
results, or we could look at supporting a variant of analyses whose
results are specifically *not* cached and expected to just be used and
discarded by the consumer. Either way, these seem like incremental
enhancements that should happen when we start profiling the memory and
CPU usage of the new pass manager and not before.
The other minor annoyance is that if we end up using the TLI in both
a module pass and a function pass, those will be produced by two
separate analyses, and thus will point to separate copies of the
implementation state. While a minor issue, I dislike this and would like
to find a way to cleanly allow a single analysis instance to be used
across multiple IR unit managers. But I don't have a good solution to
this today, and I don't want to hold up all of the work waiting to come
up with one. This too seems like a reasonable thing to incrementally
improve later.
llvm-svn: 226981
2015-01-24 10:06:09 +08:00
|
|
|
static void initialize(TargetLibraryInfoImpl &TLI, const Triple &T,
|
2016-10-01 11:10:48 +08:00
|
|
|
ArrayRef<StringRef> StandardNames) {
|
2012-08-03 12:06:22 +08:00
|
|
|
// Verify that the StandardNames array is in alphabetical order.
|
2016-01-04 03:43:40 +08:00
|
|
|
assert(std::is_sorted(StandardNames.begin(), StandardNames.end(),
|
2016-10-01 11:10:48 +08:00
|
|
|
[](StringRef LHS, StringRef RHS) {
|
|
|
|
return LHS < RHS;
|
2016-01-04 03:43:40 +08:00
|
|
|
}) &&
|
|
|
|
"TargetLibraryInfoImpl function names must be sorted");
|
2014-04-03 03:53:29 +08:00
|
|
|
|
[SimplifyLibcalls] Replace locked IO with unlocked IO
Summary: If file stream arg is not captured and source is fopen, we could replace IO calls by unlocked IO ("_unlocked" function variants) to gain better speed,
Reviewers: efriedma, RKSimon, spatel, sanjoy, hfinkel, majnemer, lebedev.ri, rja
Reviewed By: rja
Subscribers: rja, srhines, efriedma, lebedev.ri, llvm-commits
Differential Revision: https://reviews.llvm.org/D45736
llvm-svn: 332452
2018-05-16 19:39:52 +08:00
|
|
|
// Set IO unlocked variants as unavailable
|
|
|
|
// Set them as available per system below
|
|
|
|
TLI.setUnavailable(LibFunc_getchar_unlocked);
|
|
|
|
TLI.setUnavailable(LibFunc_putc_unlocked);
|
|
|
|
TLI.setUnavailable(LibFunc_putchar_unlocked);
|
|
|
|
TLI.setUnavailable(LibFunc_fputc_unlocked);
|
|
|
|
TLI.setUnavailable(LibFunc_fgetc_unlocked);
|
|
|
|
TLI.setUnavailable(LibFunc_fread_unlocked);
|
|
|
|
TLI.setUnavailable(LibFunc_fwrite_unlocked);
|
|
|
|
TLI.setUnavailable(LibFunc_fputs_unlocked);
|
|
|
|
TLI.setUnavailable(LibFunc_fgets_unlocked);
|
|
|
|
|
2016-11-22 04:20:39 +08:00
|
|
|
bool ShouldExtI32Param = false, ShouldExtI32Return = false,
|
|
|
|
ShouldSignExtI32Param = false;
|
|
|
|
// PowerPC64, Sparc64, SystemZ need signext/zeroext on i32 parameters and
|
|
|
|
// returns corresponding to C-level ints and unsigned ints.
|
|
|
|
if (T.getArch() == Triple::ppc64 || T.getArch() == Triple::ppc64le ||
|
|
|
|
T.getArch() == Triple::sparcv9 || T.getArch() == Triple::systemz) {
|
|
|
|
ShouldExtI32Param = true;
|
|
|
|
ShouldExtI32Return = true;
|
|
|
|
}
|
|
|
|
// Mips, on the other hand, needs signext on i32 parameters corresponding
|
|
|
|
// to both signed and unsigned ints.
|
2018-06-26 00:49:20 +08:00
|
|
|
if (T.isMIPS()) {
|
2016-11-22 04:20:39 +08:00
|
|
|
ShouldSignExtI32Param = true;
|
|
|
|
}
|
|
|
|
TLI.setShouldExtI32Param(ShouldExtI32Param);
|
|
|
|
TLI.setShouldExtI32Return(ShouldExtI32Return);
|
|
|
|
TLI.setShouldSignExtI32Param(ShouldSignExtI32Param);
|
|
|
|
|
2015-12-16 01:24:15 +08:00
|
|
|
if (T.getArch() == Triple::r600 ||
|
|
|
|
T.getArch() == Triple::amdgcn) {
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
TLI.setUnavailable(LibFunc_ldexp);
|
|
|
|
TLI.setUnavailable(LibFunc_ldexpf);
|
|
|
|
TLI.setUnavailable(LibFunc_ldexpl);
|
|
|
|
TLI.setUnavailable(LibFunc_exp10);
|
|
|
|
TLI.setUnavailable(LibFunc_exp10f);
|
|
|
|
TLI.setUnavailable(LibFunc_exp10l);
|
|
|
|
TLI.setUnavailable(LibFunc_log10);
|
|
|
|
TLI.setUnavailable(LibFunc_log10f);
|
|
|
|
TLI.setUnavailable(LibFunc_log10l);
|
2015-12-16 01:24:15 +08:00
|
|
|
}
|
|
|
|
|
2015-01-07 09:17:37 +08:00
|
|
|
// There are no library implementations of mempcy and memset for AMD gpus and
|
2014-04-03 03:53:29 +08:00
|
|
|
// these can be difficult to lower in the backend.
|
2015-01-07 09:17:37 +08:00
|
|
|
if (T.getArch() == Triple::r600 ||
|
2016-01-19 22:49:23 +08:00
|
|
|
T.getArch() == Triple::amdgcn) {
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
TLI.setUnavailable(LibFunc_memcpy);
|
|
|
|
TLI.setUnavailable(LibFunc_memset);
|
|
|
|
TLI.setUnavailable(LibFunc_memset_pattern16);
|
2014-04-03 03:53:29 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-03-08 02:08:54 +08:00
|
|
|
// memset_pattern16 is only available on iOS 3.0 and Mac OS X 10.5 and later.
|
2015-10-29 06:51:16 +08:00
|
|
|
// All versions of watchOS support it.
|
2011-04-20 08:14:25 +08:00
|
|
|
if (T.isMacOSX()) {
|
[SimplifyLibcalls] Replace locked IO with unlocked IO
Summary: If file stream arg is not captured and source is fopen, we could replace IO calls by unlocked IO ("_unlocked" function variants) to gain better speed,
Reviewers: efriedma, RKSimon, spatel, sanjoy, hfinkel, majnemer, lebedev.ri, rja
Reviewed By: rja
Subscribers: rja, srhines, efriedma, lebedev.ri, llvm-commits
Differential Revision: https://reviews.llvm.org/D45736
llvm-svn: 332452
2018-05-16 19:39:52 +08:00
|
|
|
// available IO unlocked variants on Mac OS X
|
|
|
|
TLI.setAvailable(LibFunc_getc_unlocked);
|
|
|
|
TLI.setAvailable(LibFunc_getchar_unlocked);
|
|
|
|
TLI.setAvailable(LibFunc_putc_unlocked);
|
|
|
|
TLI.setAvailable(LibFunc_putchar_unlocked);
|
|
|
|
|
2011-04-20 08:14:25 +08:00
|
|
|
if (T.isMacOSXVersionLT(10, 5))
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
TLI.setUnavailable(LibFunc_memset_pattern16);
|
2013-08-30 04:23:14 +08:00
|
|
|
} else if (T.isiOS()) {
|
2011-04-20 04:44:08 +08:00
|
|
|
if (T.isOSVersionLT(3, 0))
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
TLI.setUnavailable(LibFunc_memset_pattern16);
|
2015-10-29 06:51:16 +08:00
|
|
|
} else if (!T.isWatchOS()) {
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
TLI.setUnavailable(LibFunc_memset_pattern16);
|
2011-04-20 04:44:08 +08:00
|
|
|
}
|
2011-03-03 21:17:51 +08:00
|
|
|
|
2013-11-03 14:48:38 +08:00
|
|
|
if (!hasSinCosPiStret(T)) {
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
TLI.setUnavailable(LibFunc_sinpi);
|
|
|
|
TLI.setUnavailable(LibFunc_sinpif);
|
|
|
|
TLI.setUnavailable(LibFunc_cospi);
|
|
|
|
TLI.setUnavailable(LibFunc_cospif);
|
|
|
|
TLI.setUnavailable(LibFunc_sincospi_stret);
|
|
|
|
TLI.setUnavailable(LibFunc_sincospif_stret);
|
2013-11-03 14:48:38 +08:00
|
|
|
}
|
|
|
|
|
2011-11-17 09:27:36 +08:00
|
|
|
if (T.isMacOSX() && T.getArch() == Triple::x86 &&
|
|
|
|
!T.isMacOSXVersionLT(10, 7)) {
|
|
|
|
// x86-32 OSX has a scheme where fwrite and fputs (and some other functions
|
|
|
|
// we don't care about) have two versions; on recent OSX, the one we want
|
|
|
|
// has a $UNIX2003 suffix. The two implementations are identical except
|
|
|
|
// for the return value in some edge cases. However, we don't want to
|
|
|
|
// generate code that depends on the old symbols.
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
TLI.setAvailableWithName(LibFunc_fwrite, "fwrite$UNIX2003");
|
|
|
|
TLI.setAvailableWithName(LibFunc_fputs, "fputs$UNIX2003");
|
2011-11-17 09:27:36 +08:00
|
|
|
}
|
|
|
|
|
2011-06-09 19:11:45 +08:00
|
|
|
// iprintf and friends are only available on XCore and TCE.
|
|
|
|
if (T.getArch() != Triple::xcore && T.getArch() != Triple::tce) {
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
TLI.setUnavailable(LibFunc_iprintf);
|
|
|
|
TLI.setUnavailable(LibFunc_siprintf);
|
|
|
|
TLI.setUnavailable(LibFunc_fiprintf);
|
2011-03-03 22:09:28 +08:00
|
|
|
}
|
2012-04-18 07:05:54 +08:00
|
|
|
|
2014-07-25 06:09:06 +08:00
|
|
|
if (T.isOSWindows() && !T.isOSCygMing()) {
|
2012-04-18 07:05:54 +08:00
|
|
|
// Win32 does not support long double
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
TLI.setUnavailable(LibFunc_acosl);
|
|
|
|
TLI.setUnavailable(LibFunc_asinl);
|
|
|
|
TLI.setUnavailable(LibFunc_atanl);
|
|
|
|
TLI.setUnavailable(LibFunc_atan2l);
|
|
|
|
TLI.setUnavailable(LibFunc_ceill);
|
|
|
|
TLI.setUnavailable(LibFunc_copysignl);
|
|
|
|
TLI.setUnavailable(LibFunc_cosl);
|
|
|
|
TLI.setUnavailable(LibFunc_coshl);
|
|
|
|
TLI.setUnavailable(LibFunc_expl);
|
|
|
|
TLI.setUnavailable(LibFunc_fabsf); // Win32 and Win64 both lack fabsf
|
|
|
|
TLI.setUnavailable(LibFunc_fabsl);
|
|
|
|
TLI.setUnavailable(LibFunc_floorl);
|
|
|
|
TLI.setUnavailable(LibFunc_fmaxl);
|
|
|
|
TLI.setUnavailable(LibFunc_fminl);
|
|
|
|
TLI.setUnavailable(LibFunc_fmodl);
|
|
|
|
TLI.setUnavailable(LibFunc_frexpl);
|
|
|
|
TLI.setUnavailable(LibFunc_ldexpf);
|
|
|
|
TLI.setUnavailable(LibFunc_ldexpl);
|
|
|
|
TLI.setUnavailable(LibFunc_logl);
|
|
|
|
TLI.setUnavailable(LibFunc_modfl);
|
|
|
|
TLI.setUnavailable(LibFunc_powl);
|
|
|
|
TLI.setUnavailable(LibFunc_sinl);
|
|
|
|
TLI.setUnavailable(LibFunc_sinhl);
|
|
|
|
TLI.setUnavailable(LibFunc_sqrtl);
|
|
|
|
TLI.setUnavailable(LibFunc_tanl);
|
|
|
|
TLI.setUnavailable(LibFunc_tanhl);
|
2012-04-18 07:05:54 +08:00
|
|
|
|
|
|
|
// Win32 only has C89 math
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
TLI.setUnavailable(LibFunc_acosh);
|
|
|
|
TLI.setUnavailable(LibFunc_acoshf);
|
|
|
|
TLI.setUnavailable(LibFunc_acoshl);
|
|
|
|
TLI.setUnavailable(LibFunc_asinh);
|
|
|
|
TLI.setUnavailable(LibFunc_asinhf);
|
|
|
|
TLI.setUnavailable(LibFunc_asinhl);
|
|
|
|
TLI.setUnavailable(LibFunc_atanh);
|
|
|
|
TLI.setUnavailable(LibFunc_atanhf);
|
|
|
|
TLI.setUnavailable(LibFunc_atanhl);
|
2017-12-16 09:26:25 +08:00
|
|
|
TLI.setUnavailable(LibFunc_cabs);
|
|
|
|
TLI.setUnavailable(LibFunc_cabsf);
|
|
|
|
TLI.setUnavailable(LibFunc_cabsl);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
TLI.setUnavailable(LibFunc_cbrt);
|
|
|
|
TLI.setUnavailable(LibFunc_cbrtf);
|
|
|
|
TLI.setUnavailable(LibFunc_cbrtl);
|
|
|
|
TLI.setUnavailable(LibFunc_exp2);
|
|
|
|
TLI.setUnavailable(LibFunc_exp2f);
|
|
|
|
TLI.setUnavailable(LibFunc_exp2l);
|
|
|
|
TLI.setUnavailable(LibFunc_expm1);
|
|
|
|
TLI.setUnavailable(LibFunc_expm1f);
|
|
|
|
TLI.setUnavailable(LibFunc_expm1l);
|
|
|
|
TLI.setUnavailable(LibFunc_log2);
|
|
|
|
TLI.setUnavailable(LibFunc_log2f);
|
|
|
|
TLI.setUnavailable(LibFunc_log2l);
|
|
|
|
TLI.setUnavailable(LibFunc_log1p);
|
|
|
|
TLI.setUnavailable(LibFunc_log1pf);
|
|
|
|
TLI.setUnavailable(LibFunc_log1pl);
|
|
|
|
TLI.setUnavailable(LibFunc_logb);
|
|
|
|
TLI.setUnavailable(LibFunc_logbf);
|
|
|
|
TLI.setUnavailable(LibFunc_logbl);
|
|
|
|
TLI.setUnavailable(LibFunc_nearbyint);
|
|
|
|
TLI.setUnavailable(LibFunc_nearbyintf);
|
|
|
|
TLI.setUnavailable(LibFunc_nearbyintl);
|
|
|
|
TLI.setUnavailable(LibFunc_rint);
|
|
|
|
TLI.setUnavailable(LibFunc_rintf);
|
|
|
|
TLI.setUnavailable(LibFunc_rintl);
|
|
|
|
TLI.setUnavailable(LibFunc_round);
|
|
|
|
TLI.setUnavailable(LibFunc_roundf);
|
|
|
|
TLI.setUnavailable(LibFunc_roundl);
|
|
|
|
TLI.setUnavailable(LibFunc_trunc);
|
|
|
|
TLI.setUnavailable(LibFunc_truncf);
|
|
|
|
TLI.setUnavailable(LibFunc_truncl);
|
2012-04-18 07:05:54 +08:00
|
|
|
|
|
|
|
// Win32 provides some C99 math with mangled names
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
TLI.setAvailableWithName(LibFunc_copysign, "_copysign");
|
2012-04-18 07:05:54 +08:00
|
|
|
|
|
|
|
if (T.getArch() == Triple::x86) {
|
|
|
|
// Win32 on x86 implements single-precision math functions as macros
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
TLI.setUnavailable(LibFunc_acosf);
|
|
|
|
TLI.setUnavailable(LibFunc_asinf);
|
|
|
|
TLI.setUnavailable(LibFunc_atanf);
|
|
|
|
TLI.setUnavailable(LibFunc_atan2f);
|
|
|
|
TLI.setUnavailable(LibFunc_ceilf);
|
|
|
|
TLI.setUnavailable(LibFunc_copysignf);
|
|
|
|
TLI.setUnavailable(LibFunc_cosf);
|
|
|
|
TLI.setUnavailable(LibFunc_coshf);
|
|
|
|
TLI.setUnavailable(LibFunc_expf);
|
|
|
|
TLI.setUnavailable(LibFunc_floorf);
|
|
|
|
TLI.setUnavailable(LibFunc_fminf);
|
|
|
|
TLI.setUnavailable(LibFunc_fmaxf);
|
|
|
|
TLI.setUnavailable(LibFunc_fmodf);
|
|
|
|
TLI.setUnavailable(LibFunc_logf);
|
|
|
|
TLI.setUnavailable(LibFunc_log10f);
|
|
|
|
TLI.setUnavailable(LibFunc_modff);
|
|
|
|
TLI.setUnavailable(LibFunc_powf);
|
|
|
|
TLI.setUnavailable(LibFunc_sinf);
|
|
|
|
TLI.setUnavailable(LibFunc_sinhf);
|
|
|
|
TLI.setUnavailable(LibFunc_sqrtf);
|
|
|
|
TLI.setUnavailable(LibFunc_tanf);
|
|
|
|
TLI.setUnavailable(LibFunc_tanhf);
|
2012-04-18 07:05:54 +08:00
|
|
|
}
|
2012-11-10 11:11:06 +08:00
|
|
|
|
2018-03-31 06:22:31 +08:00
|
|
|
// Win32 does *not* provide these functions, but they are
|
2013-03-06 05:47:40 +08:00
|
|
|
// generally available on POSIX-compliant systems:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
TLI.setUnavailable(LibFunc_access);
|
|
|
|
TLI.setUnavailable(LibFunc_bcmp);
|
|
|
|
TLI.setUnavailable(LibFunc_bcopy);
|
|
|
|
TLI.setUnavailable(LibFunc_bzero);
|
|
|
|
TLI.setUnavailable(LibFunc_chmod);
|
|
|
|
TLI.setUnavailable(LibFunc_chown);
|
|
|
|
TLI.setUnavailable(LibFunc_closedir);
|
|
|
|
TLI.setUnavailable(LibFunc_ctermid);
|
|
|
|
TLI.setUnavailable(LibFunc_fdopen);
|
|
|
|
TLI.setUnavailable(LibFunc_ffs);
|
|
|
|
TLI.setUnavailable(LibFunc_fileno);
|
|
|
|
TLI.setUnavailable(LibFunc_flockfile);
|
|
|
|
TLI.setUnavailable(LibFunc_fseeko);
|
|
|
|
TLI.setUnavailable(LibFunc_fstat);
|
|
|
|
TLI.setUnavailable(LibFunc_fstatvfs);
|
|
|
|
TLI.setUnavailable(LibFunc_ftello);
|
|
|
|
TLI.setUnavailable(LibFunc_ftrylockfile);
|
|
|
|
TLI.setUnavailable(LibFunc_funlockfile);
|
|
|
|
TLI.setUnavailable(LibFunc_getitimer);
|
|
|
|
TLI.setUnavailable(LibFunc_getlogin_r);
|
|
|
|
TLI.setUnavailable(LibFunc_getpwnam);
|
|
|
|
TLI.setUnavailable(LibFunc_gettimeofday);
|
|
|
|
TLI.setUnavailable(LibFunc_htonl);
|
|
|
|
TLI.setUnavailable(LibFunc_htons);
|
|
|
|
TLI.setUnavailable(LibFunc_lchown);
|
|
|
|
TLI.setUnavailable(LibFunc_lstat);
|
|
|
|
TLI.setUnavailable(LibFunc_memccpy);
|
|
|
|
TLI.setUnavailable(LibFunc_mkdir);
|
|
|
|
TLI.setUnavailable(LibFunc_ntohl);
|
|
|
|
TLI.setUnavailable(LibFunc_ntohs);
|
|
|
|
TLI.setUnavailable(LibFunc_open);
|
|
|
|
TLI.setUnavailable(LibFunc_opendir);
|
|
|
|
TLI.setUnavailable(LibFunc_pclose);
|
|
|
|
TLI.setUnavailable(LibFunc_popen);
|
|
|
|
TLI.setUnavailable(LibFunc_pread);
|
|
|
|
TLI.setUnavailable(LibFunc_pwrite);
|
|
|
|
TLI.setUnavailable(LibFunc_read);
|
|
|
|
TLI.setUnavailable(LibFunc_readlink);
|
|
|
|
TLI.setUnavailable(LibFunc_realpath);
|
|
|
|
TLI.setUnavailable(LibFunc_rmdir);
|
|
|
|
TLI.setUnavailable(LibFunc_setitimer);
|
|
|
|
TLI.setUnavailable(LibFunc_stat);
|
|
|
|
TLI.setUnavailable(LibFunc_statvfs);
|
|
|
|
TLI.setUnavailable(LibFunc_stpcpy);
|
|
|
|
TLI.setUnavailable(LibFunc_stpncpy);
|
|
|
|
TLI.setUnavailable(LibFunc_strcasecmp);
|
|
|
|
TLI.setUnavailable(LibFunc_strncasecmp);
|
|
|
|
TLI.setUnavailable(LibFunc_times);
|
|
|
|
TLI.setUnavailable(LibFunc_uname);
|
|
|
|
TLI.setUnavailable(LibFunc_unlink);
|
|
|
|
TLI.setUnavailable(LibFunc_unsetenv);
|
|
|
|
TLI.setUnavailable(LibFunc_utime);
|
|
|
|
TLI.setUnavailable(LibFunc_utimes);
|
|
|
|
TLI.setUnavailable(LibFunc_write);
|
2012-11-22 23:36:42 +08:00
|
|
|
|
2013-03-06 05:47:40 +08:00
|
|
|
// Win32 does *not* provide provide these functions, but they are
|
|
|
|
// specified by C99:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
TLI.setUnavailable(LibFunc_atoll);
|
|
|
|
TLI.setUnavailable(LibFunc_frexpf);
|
|
|
|
TLI.setUnavailable(LibFunc_llabs);
|
2013-12-27 03:17:04 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
switch (T.getOS()) {
|
|
|
|
case Triple::MacOSX:
|
2013-12-28 10:40:19 +08:00
|
|
|
// exp10 and exp10f are not available on OS X until 10.9 and iOS until 7.0
|
|
|
|
// and their names are __exp10 and __exp10f. exp10l is not available on
|
|
|
|
// OS X or iOS.
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
TLI.setUnavailable(LibFunc_exp10l);
|
2013-12-27 03:17:04 +08:00
|
|
|
if (T.isMacOSXVersionLT(10, 9)) {
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
TLI.setUnavailable(LibFunc_exp10);
|
|
|
|
TLI.setUnavailable(LibFunc_exp10f);
|
2013-12-27 03:17:04 +08:00
|
|
|
} else {
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
TLI.setAvailableWithName(LibFunc_exp10, "__exp10");
|
|
|
|
TLI.setAvailableWithName(LibFunc_exp10f, "__exp10f");
|
2013-12-27 03:17:04 +08:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
case Triple::IOS:
|
2015-11-03 02:00:00 +08:00
|
|
|
case Triple::TvOS:
|
2015-10-29 06:51:16 +08:00
|
|
|
case Triple::WatchOS:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
TLI.setUnavailable(LibFunc_exp10l);
|
2015-10-29 06:51:16 +08:00
|
|
|
if (!T.isWatchOS() && (T.isOSVersionLT(7, 0) ||
|
|
|
|
(T.isOSVersionLT(9, 0) &&
|
|
|
|
(T.getArch() == Triple::x86 ||
|
|
|
|
T.getArch() == Triple::x86_64)))) {
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
TLI.setUnavailable(LibFunc_exp10);
|
|
|
|
TLI.setUnavailable(LibFunc_exp10f);
|
2013-12-27 03:17:04 +08:00
|
|
|
} else {
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
TLI.setAvailableWithName(LibFunc_exp10, "__exp10");
|
|
|
|
TLI.setAvailableWithName(LibFunc_exp10f, "__exp10f");
|
2013-12-27 03:17:04 +08:00
|
|
|
}
|
|
|
|
break;
|
2013-12-28 10:40:19 +08:00
|
|
|
case Triple::Linux:
|
|
|
|
// exp10, exp10f, exp10l is available on Linux (GLIBC) but are extremely
|
|
|
|
// buggy prior to glibc version 2.18. Until this version is widely deployed
|
|
|
|
// or we have a reasonable detection strategy, we cannot use exp10 reliably
|
|
|
|
// on Linux.
|
|
|
|
//
|
|
|
|
// Fall through to disable all of them.
|
2016-08-18 04:30:52 +08:00
|
|
|
LLVM_FALLTHROUGH;
|
2013-12-27 03:17:04 +08:00
|
|
|
default:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
TLI.setUnavailable(LibFunc_exp10);
|
|
|
|
TLI.setUnavailable(LibFunc_exp10f);
|
|
|
|
TLI.setUnavailable(LibFunc_exp10l);
|
2012-11-22 23:36:42 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// ffsl is available on at least Darwin, Mac OS X, iOS, FreeBSD, and
|
|
|
|
// Linux (GLIBC):
|
|
|
|
// http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/ffsl.3.html
|
2015-11-02 01:00:13 +08:00
|
|
|
// http://svn.freebsd.org/base/head/lib/libc/string/ffsl.c
|
2012-11-22 23:36:42 +08:00
|
|
|
// http://www.gnu.org/software/gnulib/manual/html_node/ffsl.html
|
|
|
|
switch (T.getOS()) {
|
|
|
|
case Triple::Darwin:
|
|
|
|
case Triple::MacOSX:
|
|
|
|
case Triple::IOS:
|
2015-11-03 02:00:00 +08:00
|
|
|
case Triple::TvOS:
|
2015-10-29 06:51:16 +08:00
|
|
|
case Triple::WatchOS:
|
2012-11-22 23:36:42 +08:00
|
|
|
case Triple::FreeBSD:
|
|
|
|
case Triple::Linux:
|
|
|
|
break;
|
|
|
|
default:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
TLI.setUnavailable(LibFunc_ffsl);
|
2012-11-22 23:36:42 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// ffsll is available on at least FreeBSD and Linux (GLIBC):
|
2015-11-02 01:00:13 +08:00
|
|
|
// http://svn.freebsd.org/base/head/lib/libc/string/ffsll.c
|
2012-11-22 23:36:42 +08:00
|
|
|
// http://www.gnu.org/software/gnulib/manual/html_node/ffsll.html
|
|
|
|
switch (T.getOS()) {
|
2015-11-03 02:00:00 +08:00
|
|
|
case Triple::Darwin:
|
|
|
|
case Triple::MacOSX:
|
|
|
|
case Triple::IOS:
|
|
|
|
case Triple::TvOS:
|
|
|
|
case Triple::WatchOS:
|
2012-11-22 23:36:42 +08:00
|
|
|
case Triple::FreeBSD:
|
|
|
|
case Triple::Linux:
|
|
|
|
break;
|
|
|
|
default:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
TLI.setUnavailable(LibFunc_ffsll);
|
2012-04-18 07:05:54 +08:00
|
|
|
}
|
2013-03-06 05:47:40 +08:00
|
|
|
|
2015-11-10 07:23:20 +08:00
|
|
|
// The following functions are available on at least FreeBSD:
|
|
|
|
// http://svn.freebsd.org/base/head/lib/libc/string/fls.c
|
|
|
|
// http://svn.freebsd.org/base/head/lib/libc/string/flsl.c
|
|
|
|
// http://svn.freebsd.org/base/head/lib/libc/string/flsll.c
|
|
|
|
if (!T.isOSFreeBSD()) {
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
TLI.setUnavailable(LibFunc_fls);
|
|
|
|
TLI.setUnavailable(LibFunc_flsl);
|
|
|
|
TLI.setUnavailable(LibFunc_flsll);
|
2015-11-10 07:23:20 +08:00
|
|
|
}
|
|
|
|
|
2018-11-07 02:23:32 +08:00
|
|
|
// The following functions are only available on GNU/Linux (using glibc).
|
|
|
|
// Linux variants without glibc (eg: bionic, musl) may have some subset.
|
|
|
|
if (!T.isOSLinux() || !T.isGNUEnvironment()) {
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
TLI.setUnavailable(LibFunc_dunder_strdup);
|
|
|
|
TLI.setUnavailable(LibFunc_dunder_strtok_r);
|
|
|
|
TLI.setUnavailable(LibFunc_dunder_isoc99_scanf);
|
|
|
|
TLI.setUnavailable(LibFunc_dunder_isoc99_sscanf);
|
|
|
|
TLI.setUnavailable(LibFunc_under_IO_getc);
|
|
|
|
TLI.setUnavailable(LibFunc_under_IO_putc);
|
2018-11-07 02:23:32 +08:00
|
|
|
// But, Android and musl have memalign.
|
|
|
|
if (!T.isAndroid() && !T.isMusl())
|
2018-02-01 03:12:50 +08:00
|
|
|
TLI.setUnavailable(LibFunc_memalign);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
TLI.setUnavailable(LibFunc_fopen64);
|
|
|
|
TLI.setUnavailable(LibFunc_fseeko64);
|
|
|
|
TLI.setUnavailable(LibFunc_fstat64);
|
|
|
|
TLI.setUnavailable(LibFunc_fstatvfs64);
|
|
|
|
TLI.setUnavailable(LibFunc_ftello64);
|
|
|
|
TLI.setUnavailable(LibFunc_lstat64);
|
|
|
|
TLI.setUnavailable(LibFunc_open64);
|
|
|
|
TLI.setUnavailable(LibFunc_stat64);
|
|
|
|
TLI.setUnavailable(LibFunc_statvfs64);
|
|
|
|
TLI.setUnavailable(LibFunc_tmpfile64);
|
2018-01-09 01:38:09 +08:00
|
|
|
|
|
|
|
// Relaxed math functions are included in math-finite.h on Linux (GLIBC).
|
|
|
|
TLI.setUnavailable(LibFunc_acos_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_acosf_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_acosl_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_acosh_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_acoshf_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_acoshl_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_asin_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_asinf_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_asinl_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_atan2_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_atan2f_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_atan2l_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_atanh_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_atanhf_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_atanhl_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_cosh_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_coshf_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_coshl_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_exp10_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_exp10f_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_exp10l_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_exp2_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_exp2f_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_exp2l_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_exp_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_expf_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_expl_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_log10_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_log10f_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_log10l_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_log2_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_log2f_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_log2l_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_log_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_logf_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_logl_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_pow_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_powf_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_powl_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_sinh_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_sinhf_finite);
|
|
|
|
TLI.setUnavailable(LibFunc_sinhl_finite);
|
2013-03-06 05:47:40 +08:00
|
|
|
}
|
2015-03-18 03:50:55 +08:00
|
|
|
|
2018-05-17 16:16:08 +08:00
|
|
|
if ((T.isOSLinux() && T.isGNUEnvironment()) ||
|
|
|
|
(T.isAndroid() && !T.isAndroidVersionLT(28))) {
|
[SimplifyLibcalls] Replace locked IO with unlocked IO
Summary: If file stream arg is not captured and source is fopen, we could replace IO calls by unlocked IO ("_unlocked" function variants) to gain better speed,
Reviewers: efriedma, RKSimon, spatel, sanjoy, hfinkel, majnemer, lebedev.ri, rja
Reviewed By: rja
Subscribers: rja, srhines, efriedma, lebedev.ri, llvm-commits
Differential Revision: https://reviews.llvm.org/D45736
llvm-svn: 332452
2018-05-16 19:39:52 +08:00
|
|
|
// available IO unlocked variants on GNU/Linux and Android P or later
|
|
|
|
TLI.setAvailable(LibFunc_getc_unlocked);
|
|
|
|
TLI.setAvailable(LibFunc_getchar_unlocked);
|
|
|
|
TLI.setAvailable(LibFunc_putc_unlocked);
|
|
|
|
TLI.setAvailable(LibFunc_putchar_unlocked);
|
|
|
|
TLI.setAvailable(LibFunc_fputc_unlocked);
|
|
|
|
TLI.setAvailable(LibFunc_fgetc_unlocked);
|
|
|
|
TLI.setAvailable(LibFunc_fread_unlocked);
|
|
|
|
TLI.setAvailable(LibFunc_fwrite_unlocked);
|
|
|
|
TLI.setAvailable(LibFunc_fputs_unlocked);
|
|
|
|
TLI.setAvailable(LibFunc_fgets_unlocked);
|
|
|
|
}
|
|
|
|
|
2016-01-27 07:51:06 +08:00
|
|
|
// As currently implemented in clang, NVPTX code has no standard library to
|
|
|
|
// speak of. Headers provide a standard-ish library implementation, but many
|
|
|
|
// of the signatures are wrong -- for example, many libm functions are not
|
|
|
|
// extern "C".
|
|
|
|
//
|
|
|
|
// libdevice, an IR library provided by nvidia, is linked in by the front-end,
|
|
|
|
// but only used functions are provided to llvm. Moreover, most of the
|
|
|
|
// functions in libdevice don't map precisely to standard library functions.
|
|
|
|
//
|
|
|
|
// FIXME: Having no standard library prevents e.g. many fastmath
|
|
|
|
// optimizations, so this situation should be fixed.
|
2016-04-01 05:29:57 +08:00
|
|
|
if (T.isNVPTX()) {
|
2016-01-27 07:51:06 +08:00
|
|
|
TLI.disableAllFunctions();
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
TLI.setAvailable(LibFunc_nvvm_reflect);
|
2016-04-01 05:29:57 +08:00
|
|
|
} else {
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
TLI.setUnavailable(LibFunc_nvvm_reflect);
|
2016-04-01 05:29:57 +08:00
|
|
|
}
|
2016-01-27 07:51:06 +08:00
|
|
|
|
2015-03-18 03:50:55 +08:00
|
|
|
TLI.addVectorizableFunctionsFromVecLib(ClVectorLibrary);
|
2011-02-19 05:50:34 +08:00
|
|
|
}
|
|
|
|
|
[PM] Rework how the TargetLibraryInfo pass integrates with the new pass
manager to support the actual uses of it. =]
When I ported instcombine to the new pass manager I discover that it
didn't work because TLI wasn't available in the right places. This is
a somewhat surprising and/or subtle aspect of the new pass manager
design that came up before but I think is useful to be reminded of:
While the new pass manager *allows* a function pass to query a module
analysis, it requires that the module analysis is already run and cached
prior to the function pass manager starting up, possibly with
a 'require<foo>' style utility in the pass pipeline. This is an
intentional hurdle because using a module analysis from a function pass
*requires* that the module analysis is run prior to entering the
function pass manager. Otherwise the other functions in the module could
be in who-knows-what state, etc.
A somewhat surprising consequence of this design decision (at least to
me) is that you have to design a function pass that leverages
a module analysis to do so as an optional feature. Even if that means
your function pass does no work in the absence of the module analysis,
you have to handle that possibility and remain conservatively correct.
This is a natural consequence of things being able to invalidate the
module analysis and us being unable to re-run it. And it's a generally
good thing because it lets us reorder passes arbitrarily without
breaking correctness, etc.
This ends up causing problems in one case. What if we have a module
analysis that is *definitionally* impossible to invalidate. In the
places this might come up, the analysis is usually also definitionally
trivial to run even while other transformation passes run on the module,
regardless of the state of anything. And so, it follows that it is
natural to have a hard requirement on such analyses from a function
pass.
It turns out, that TargetLibraryInfo is just such an analysis, and
InstCombine has a hard requirement on it.
The approach I've taken here is to produce an analysis that models this
flexibility by making it both a module and a function analysis. This
exposes the fact that it is in fact safe to compute at any point. We can
even make it a valid CGSCC analysis at some point if that is useful.
However, we don't want to have a copy of the actual target library info
state for each function! This state is specific to the triple. The
somewhat direct and blunt approach here is to turn TLI into a pimpl,
with the state and mutators in the implementation class and the query
routines primarily in the wrapper. Then the analysis can lazily
construct and cache the implementations, keyed on the triple, and
on-demand produce wrappers of them for each function.
One minor annoyance is that we will end up with a wrapper for each
function in the module. While this is a bit wasteful (one pointer per
function) it seems tolerable. And it has the advantage of ensuring that
we pay the absolute minimum synchronization cost to access this
information should we end up with a nice parallel function pass manager
in the future. We could look into trying to mark when analysis results
are especially cheap to recompute and more eagerly GC-ing the cached
results, or we could look at supporting a variant of analyses whose
results are specifically *not* cached and expected to just be used and
discarded by the consumer. Either way, these seem like incremental
enhancements that should happen when we start profiling the memory and
CPU usage of the new pass manager and not before.
The other minor annoyance is that if we end up using the TLI in both
a module pass and a function pass, those will be produced by two
separate analyses, and thus will point to separate copies of the
implementation state. While a minor issue, I dislike this and would like
to find a way to cleanly allow a single analysis instance to be used
across multiple IR unit managers. But I don't have a good solution to
this today, and I don't want to hold up all of the work waiting to come
up with one. This too seems like a reasonable thing to incrementally
improve later.
llvm-svn: 226981
2015-01-24 10:06:09 +08:00
|
|
|
TargetLibraryInfoImpl::TargetLibraryInfoImpl() {
|
2011-02-19 05:50:34 +08:00
|
|
|
// Default to everything being available.
|
|
|
|
memset(AvailableArray, -1, sizeof(AvailableArray));
|
|
|
|
|
2012-08-03 12:06:22 +08:00
|
|
|
initialize(*this, Triple(), StandardNames);
|
2011-02-19 05:50:34 +08:00
|
|
|
}
|
|
|
|
|
2018-11-24 14:41:39 +08:00
|
|
|
TargetLibraryInfoImpl::TargetLibraryInfoImpl(const Triple &T)
|
|
|
|
: TT(T) {
|
2011-02-19 05:50:34 +08:00
|
|
|
// Default to everything being available.
|
|
|
|
memset(AvailableArray, -1, sizeof(AvailableArray));
|
2015-01-15 18:41:28 +08:00
|
|
|
|
2012-08-03 12:06:22 +08:00
|
|
|
initialize(*this, T, StandardNames);
|
2011-02-19 05:50:34 +08:00
|
|
|
}
|
2011-02-19 06:34:03 +08:00
|
|
|
|
[PM] Rework how the TargetLibraryInfo pass integrates with the new pass
manager to support the actual uses of it. =]
When I ported instcombine to the new pass manager I discover that it
didn't work because TLI wasn't available in the right places. This is
a somewhat surprising and/or subtle aspect of the new pass manager
design that came up before but I think is useful to be reminded of:
While the new pass manager *allows* a function pass to query a module
analysis, it requires that the module analysis is already run and cached
prior to the function pass manager starting up, possibly with
a 'require<foo>' style utility in the pass pipeline. This is an
intentional hurdle because using a module analysis from a function pass
*requires* that the module analysis is run prior to entering the
function pass manager. Otherwise the other functions in the module could
be in who-knows-what state, etc.
A somewhat surprising consequence of this design decision (at least to
me) is that you have to design a function pass that leverages
a module analysis to do so as an optional feature. Even if that means
your function pass does no work in the absence of the module analysis,
you have to handle that possibility and remain conservatively correct.
This is a natural consequence of things being able to invalidate the
module analysis and us being unable to re-run it. And it's a generally
good thing because it lets us reorder passes arbitrarily without
breaking correctness, etc.
This ends up causing problems in one case. What if we have a module
analysis that is *definitionally* impossible to invalidate. In the
places this might come up, the analysis is usually also definitionally
trivial to run even while other transformation passes run on the module,
regardless of the state of anything. And so, it follows that it is
natural to have a hard requirement on such analyses from a function
pass.
It turns out, that TargetLibraryInfo is just such an analysis, and
InstCombine has a hard requirement on it.
The approach I've taken here is to produce an analysis that models this
flexibility by making it both a module and a function analysis. This
exposes the fact that it is in fact safe to compute at any point. We can
even make it a valid CGSCC analysis at some point if that is useful.
However, we don't want to have a copy of the actual target library info
state for each function! This state is specific to the triple. The
somewhat direct and blunt approach here is to turn TLI into a pimpl,
with the state and mutators in the implementation class and the query
routines primarily in the wrapper. Then the analysis can lazily
construct and cache the implementations, keyed on the triple, and
on-demand produce wrappers of them for each function.
One minor annoyance is that we will end up with a wrapper for each
function in the module. While this is a bit wasteful (one pointer per
function) it seems tolerable. And it has the advantage of ensuring that
we pay the absolute minimum synchronization cost to access this
information should we end up with a nice parallel function pass manager
in the future. We could look into trying to mark when analysis results
are especially cheap to recompute and more eagerly GC-ing the cached
results, or we could look at supporting a variant of analyses whose
results are specifically *not* cached and expected to just be used and
discarded by the consumer. Either way, these seem like incremental
enhancements that should happen when we start profiling the memory and
CPU usage of the new pass manager and not before.
The other minor annoyance is that if we end up using the TLI in both
a module pass and a function pass, those will be produced by two
separate analyses, and thus will point to separate copies of the
implementation state. While a minor issue, I dislike this and would like
to find a way to cleanly allow a single analysis instance to be used
across multiple IR unit managers. But I don't have a good solution to
this today, and I don't want to hold up all of the work waiting to come
up with one. This too seems like a reasonable thing to incrementally
improve later.
llvm-svn: 226981
2015-01-24 10:06:09 +08:00
|
|
|
TargetLibraryInfoImpl::TargetLibraryInfoImpl(const TargetLibraryInfoImpl &TLI)
|
2018-11-24 14:41:39 +08:00
|
|
|
: TT(TLI.TT), CustomNames(TLI.CustomNames),
|
|
|
|
ShouldExtI32Param(TLI.ShouldExtI32Param),
|
2016-11-21 19:57:11 +08:00
|
|
|
ShouldExtI32Return(TLI.ShouldExtI32Return),
|
|
|
|
ShouldSignExtI32Param(TLI.ShouldSignExtI32Param) {
|
2011-05-22 04:09:13 +08:00
|
|
|
memcpy(AvailableArray, TLI.AvailableArray, sizeof(AvailableArray));
|
2015-03-18 03:22:30 +08:00
|
|
|
VectorDescs = TLI.VectorDescs;
|
|
|
|
ScalarDescs = TLI.ScalarDescs;
|
2015-01-15 19:39:46 +08:00
|
|
|
}
|
|
|
|
|
[PM] Rework how the TargetLibraryInfo pass integrates with the new pass
manager to support the actual uses of it. =]
When I ported instcombine to the new pass manager I discover that it
didn't work because TLI wasn't available in the right places. This is
a somewhat surprising and/or subtle aspect of the new pass manager
design that came up before but I think is useful to be reminded of:
While the new pass manager *allows* a function pass to query a module
analysis, it requires that the module analysis is already run and cached
prior to the function pass manager starting up, possibly with
a 'require<foo>' style utility in the pass pipeline. This is an
intentional hurdle because using a module analysis from a function pass
*requires* that the module analysis is run prior to entering the
function pass manager. Otherwise the other functions in the module could
be in who-knows-what state, etc.
A somewhat surprising consequence of this design decision (at least to
me) is that you have to design a function pass that leverages
a module analysis to do so as an optional feature. Even if that means
your function pass does no work in the absence of the module analysis,
you have to handle that possibility and remain conservatively correct.
This is a natural consequence of things being able to invalidate the
module analysis and us being unable to re-run it. And it's a generally
good thing because it lets us reorder passes arbitrarily without
breaking correctness, etc.
This ends up causing problems in one case. What if we have a module
analysis that is *definitionally* impossible to invalidate. In the
places this might come up, the analysis is usually also definitionally
trivial to run even while other transformation passes run on the module,
regardless of the state of anything. And so, it follows that it is
natural to have a hard requirement on such analyses from a function
pass.
It turns out, that TargetLibraryInfo is just such an analysis, and
InstCombine has a hard requirement on it.
The approach I've taken here is to produce an analysis that models this
flexibility by making it both a module and a function analysis. This
exposes the fact that it is in fact safe to compute at any point. We can
even make it a valid CGSCC analysis at some point if that is useful.
However, we don't want to have a copy of the actual target library info
state for each function! This state is specific to the triple. The
somewhat direct and blunt approach here is to turn TLI into a pimpl,
with the state and mutators in the implementation class and the query
routines primarily in the wrapper. Then the analysis can lazily
construct and cache the implementations, keyed on the triple, and
on-demand produce wrappers of them for each function.
One minor annoyance is that we will end up with a wrapper for each
function in the module. While this is a bit wasteful (one pointer per
function) it seems tolerable. And it has the advantage of ensuring that
we pay the absolute minimum synchronization cost to access this
information should we end up with a nice parallel function pass manager
in the future. We could look into trying to mark when analysis results
are especially cheap to recompute and more eagerly GC-ing the cached
results, or we could look at supporting a variant of analyses whose
results are specifically *not* cached and expected to just be used and
discarded by the consumer. Either way, these seem like incremental
enhancements that should happen when we start profiling the memory and
CPU usage of the new pass manager and not before.
The other minor annoyance is that if we end up using the TLI in both
a module pass and a function pass, those will be produced by two
separate analyses, and thus will point to separate copies of the
implementation state. While a minor issue, I dislike this and would like
to find a way to cleanly allow a single analysis instance to be used
across multiple IR unit managers. But I don't have a good solution to
this today, and I don't want to hold up all of the work waiting to come
up with one. This too seems like a reasonable thing to incrementally
improve later.
llvm-svn: 226981
2015-01-24 10:06:09 +08:00
|
|
|
TargetLibraryInfoImpl::TargetLibraryInfoImpl(TargetLibraryInfoImpl &&TLI)
|
2018-11-24 14:41:39 +08:00
|
|
|
: TT(std::move(TLI.TT)), CustomNames(std::move(TLI.CustomNames)),
|
2016-11-21 19:57:11 +08:00
|
|
|
ShouldExtI32Param(TLI.ShouldExtI32Param),
|
|
|
|
ShouldExtI32Return(TLI.ShouldExtI32Return),
|
|
|
|
ShouldSignExtI32Param(TLI.ShouldSignExtI32Param) {
|
2015-01-15 19:39:46 +08:00
|
|
|
std::move(std::begin(TLI.AvailableArray), std::end(TLI.AvailableArray),
|
|
|
|
AvailableArray);
|
2015-03-18 03:22:30 +08:00
|
|
|
VectorDescs = TLI.VectorDescs;
|
|
|
|
ScalarDescs = TLI.ScalarDescs;
|
2015-01-15 19:39:46 +08:00
|
|
|
}
|
|
|
|
|
[PM] Rework how the TargetLibraryInfo pass integrates with the new pass
manager to support the actual uses of it. =]
When I ported instcombine to the new pass manager I discover that it
didn't work because TLI wasn't available in the right places. This is
a somewhat surprising and/or subtle aspect of the new pass manager
design that came up before but I think is useful to be reminded of:
While the new pass manager *allows* a function pass to query a module
analysis, it requires that the module analysis is already run and cached
prior to the function pass manager starting up, possibly with
a 'require<foo>' style utility in the pass pipeline. This is an
intentional hurdle because using a module analysis from a function pass
*requires* that the module analysis is run prior to entering the
function pass manager. Otherwise the other functions in the module could
be in who-knows-what state, etc.
A somewhat surprising consequence of this design decision (at least to
me) is that you have to design a function pass that leverages
a module analysis to do so as an optional feature. Even if that means
your function pass does no work in the absence of the module analysis,
you have to handle that possibility and remain conservatively correct.
This is a natural consequence of things being able to invalidate the
module analysis and us being unable to re-run it. And it's a generally
good thing because it lets us reorder passes arbitrarily without
breaking correctness, etc.
This ends up causing problems in one case. What if we have a module
analysis that is *definitionally* impossible to invalidate. In the
places this might come up, the analysis is usually also definitionally
trivial to run even while other transformation passes run on the module,
regardless of the state of anything. And so, it follows that it is
natural to have a hard requirement on such analyses from a function
pass.
It turns out, that TargetLibraryInfo is just such an analysis, and
InstCombine has a hard requirement on it.
The approach I've taken here is to produce an analysis that models this
flexibility by making it both a module and a function analysis. This
exposes the fact that it is in fact safe to compute at any point. We can
even make it a valid CGSCC analysis at some point if that is useful.
However, we don't want to have a copy of the actual target library info
state for each function! This state is specific to the triple. The
somewhat direct and blunt approach here is to turn TLI into a pimpl,
with the state and mutators in the implementation class and the query
routines primarily in the wrapper. Then the analysis can lazily
construct and cache the implementations, keyed on the triple, and
on-demand produce wrappers of them for each function.
One minor annoyance is that we will end up with a wrapper for each
function in the module. While this is a bit wasteful (one pointer per
function) it seems tolerable. And it has the advantage of ensuring that
we pay the absolute minimum synchronization cost to access this
information should we end up with a nice parallel function pass manager
in the future. We could look into trying to mark when analysis results
are especially cheap to recompute and more eagerly GC-ing the cached
results, or we could look at supporting a variant of analyses whose
results are specifically *not* cached and expected to just be used and
discarded by the consumer. Either way, these seem like incremental
enhancements that should happen when we start profiling the memory and
CPU usage of the new pass manager and not before.
The other minor annoyance is that if we end up using the TLI in both
a module pass and a function pass, those will be produced by two
separate analyses, and thus will point to separate copies of the
implementation state. While a minor issue, I dislike this and would like
to find a way to cleanly allow a single analysis instance to be used
across multiple IR unit managers. But I don't have a good solution to
this today, and I don't want to hold up all of the work waiting to come
up with one. This too seems like a reasonable thing to incrementally
improve later.
llvm-svn: 226981
2015-01-24 10:06:09 +08:00
|
|
|
TargetLibraryInfoImpl &TargetLibraryInfoImpl::operator=(const TargetLibraryInfoImpl &TLI) {
|
2018-11-24 14:41:39 +08:00
|
|
|
TT = TLI.TT;
|
2011-11-17 09:27:36 +08:00
|
|
|
CustomNames = TLI.CustomNames;
|
2016-11-21 19:57:11 +08:00
|
|
|
ShouldExtI32Param = TLI.ShouldExtI32Param;
|
|
|
|
ShouldExtI32Return = TLI.ShouldExtI32Return;
|
|
|
|
ShouldSignExtI32Param = TLI.ShouldSignExtI32Param;
|
2015-01-15 19:39:46 +08:00
|
|
|
memcpy(AvailableArray, TLI.AvailableArray, sizeof(AvailableArray));
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
[PM] Rework how the TargetLibraryInfo pass integrates with the new pass
manager to support the actual uses of it. =]
When I ported instcombine to the new pass manager I discover that it
didn't work because TLI wasn't available in the right places. This is
a somewhat surprising and/or subtle aspect of the new pass manager
design that came up before but I think is useful to be reminded of:
While the new pass manager *allows* a function pass to query a module
analysis, it requires that the module analysis is already run and cached
prior to the function pass manager starting up, possibly with
a 'require<foo>' style utility in the pass pipeline. This is an
intentional hurdle because using a module analysis from a function pass
*requires* that the module analysis is run prior to entering the
function pass manager. Otherwise the other functions in the module could
be in who-knows-what state, etc.
A somewhat surprising consequence of this design decision (at least to
me) is that you have to design a function pass that leverages
a module analysis to do so as an optional feature. Even if that means
your function pass does no work in the absence of the module analysis,
you have to handle that possibility and remain conservatively correct.
This is a natural consequence of things being able to invalidate the
module analysis and us being unable to re-run it. And it's a generally
good thing because it lets us reorder passes arbitrarily without
breaking correctness, etc.
This ends up causing problems in one case. What if we have a module
analysis that is *definitionally* impossible to invalidate. In the
places this might come up, the analysis is usually also definitionally
trivial to run even while other transformation passes run on the module,
regardless of the state of anything. And so, it follows that it is
natural to have a hard requirement on such analyses from a function
pass.
It turns out, that TargetLibraryInfo is just such an analysis, and
InstCombine has a hard requirement on it.
The approach I've taken here is to produce an analysis that models this
flexibility by making it both a module and a function analysis. This
exposes the fact that it is in fact safe to compute at any point. We can
even make it a valid CGSCC analysis at some point if that is useful.
However, we don't want to have a copy of the actual target library info
state for each function! This state is specific to the triple. The
somewhat direct and blunt approach here is to turn TLI into a pimpl,
with the state and mutators in the implementation class and the query
routines primarily in the wrapper. Then the analysis can lazily
construct and cache the implementations, keyed on the triple, and
on-demand produce wrappers of them for each function.
One minor annoyance is that we will end up with a wrapper for each
function in the module. While this is a bit wasteful (one pointer per
function) it seems tolerable. And it has the advantage of ensuring that
we pay the absolute minimum synchronization cost to access this
information should we end up with a nice parallel function pass manager
in the future. We could look into trying to mark when analysis results
are especially cheap to recompute and more eagerly GC-ing the cached
results, or we could look at supporting a variant of analyses whose
results are specifically *not* cached and expected to just be used and
discarded by the consumer. Either way, these seem like incremental
enhancements that should happen when we start profiling the memory and
CPU usage of the new pass manager and not before.
The other minor annoyance is that if we end up using the TLI in both
a module pass and a function pass, those will be produced by two
separate analyses, and thus will point to separate copies of the
implementation state. While a minor issue, I dislike this and would like
to find a way to cleanly allow a single analysis instance to be used
across multiple IR unit managers. But I don't have a good solution to
this today, and I don't want to hold up all of the work waiting to come
up with one. This too seems like a reasonable thing to incrementally
improve later.
llvm-svn: 226981
2015-01-24 10:06:09 +08:00
|
|
|
TargetLibraryInfoImpl &TargetLibraryInfoImpl::operator=(TargetLibraryInfoImpl &&TLI) {
|
2018-11-24 14:41:39 +08:00
|
|
|
TT = std::move(TLI.TT);
|
2015-01-15 19:39:46 +08:00
|
|
|
CustomNames = std::move(TLI.CustomNames);
|
2016-11-21 19:57:11 +08:00
|
|
|
ShouldExtI32Param = TLI.ShouldExtI32Param;
|
|
|
|
ShouldExtI32Return = TLI.ShouldExtI32Return;
|
|
|
|
ShouldSignExtI32Param = TLI.ShouldSignExtI32Param;
|
2015-01-15 19:39:46 +08:00
|
|
|
std::move(std::begin(TLI.AvailableArray), std::end(TLI.AvailableArray),
|
|
|
|
AvailableArray);
|
|
|
|
return *this;
|
2011-05-22 04:09:13 +08:00
|
|
|
}
|
|
|
|
|
2015-03-03 07:24:40 +08:00
|
|
|
static StringRef sanitizeFunctionName(StringRef funcName) {
|
2013-03-09 21:48:23 +08:00
|
|
|
// Filter out empty names and names containing null bytes, those can't be in
|
|
|
|
// our table.
|
|
|
|
if (funcName.empty() || funcName.find('\0') != StringRef::npos)
|
2015-03-03 07:24:40 +08:00
|
|
|
return StringRef();
|
2013-03-09 21:48:23 +08:00
|
|
|
|
2013-03-06 05:47:40 +08:00
|
|
|
// Check for \01 prefix that is used to mangle __asm declarations and
|
|
|
|
// strip it if present.
|
2017-05-16 08:39:01 +08:00
|
|
|
return GlobalValue::dropLLVMManglingEscape(funcName);
|
2015-03-03 07:24:40 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
bool TargetLibraryInfoImpl::getLibFunc(StringRef funcName,
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
LibFunc &F) const {
|
2016-10-01 11:10:48 +08:00
|
|
|
StringRef const *Start = &StandardNames[0];
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
StringRef const *End = &StandardNames[NumLibFuncs];
|
2015-03-03 07:24:40 +08:00
|
|
|
|
|
|
|
funcName = sanitizeFunctionName(funcName);
|
|
|
|
if (funcName.empty())
|
|
|
|
return false;
|
|
|
|
|
2016-10-01 11:10:48 +08:00
|
|
|
StringRef const *I = std::lower_bound(
|
|
|
|
Start, End, funcName, [](StringRef LHS, StringRef RHS) {
|
|
|
|
return LHS < RHS;
|
2015-03-03 04:50:08 +08:00
|
|
|
});
|
2012-08-03 12:06:22 +08:00
|
|
|
if (I != End && *I == funcName) {
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
F = (LibFunc)(I - Start);
|
2012-08-03 12:06:22 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
2011-05-22 04:09:13 +08:00
|
|
|
|
2016-04-28 03:04:35 +08:00
|
|
|
bool TargetLibraryInfoImpl::isValidProtoForLibFunc(const FunctionType &FTy,
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
LibFunc F,
|
2016-04-28 03:04:35 +08:00
|
|
|
const DataLayout *DL) const {
|
|
|
|
LLVMContext &Ctx = FTy.getContext();
|
|
|
|
Type *PCharTy = Type::getInt8PtrTy(Ctx);
|
|
|
|
Type *SizeTTy = DL ? DL->getIntPtrType(Ctx, /*AS=*/0) : nullptr;
|
|
|
|
auto IsSizeTTy = [SizeTTy](Type *Ty) {
|
|
|
|
return SizeTTy ? Ty == SizeTTy : Ty->isIntegerTy();
|
|
|
|
};
|
|
|
|
unsigned NumParams = FTy.getNumParams();
|
|
|
|
|
|
|
|
switch (F) {
|
2018-11-07 21:49:17 +08:00
|
|
|
case LibFunc_execl:
|
|
|
|
case LibFunc_execlp:
|
|
|
|
case LibFunc_execle:
|
2018-11-07 22:46:26 +08:00
|
|
|
return (NumParams >= 2 && FTy.getParamType(0)->isPointerTy() &&
|
2018-11-07 21:49:17 +08:00
|
|
|
FTy.getParamType(1)->isPointerTy() &&
|
|
|
|
FTy.getReturnType()->isIntegerTy(32));
|
|
|
|
case LibFunc_execv:
|
|
|
|
case LibFunc_execvp:
|
|
|
|
return (NumParams == 2 && FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getParamType(1)->isPointerTy() &&
|
|
|
|
FTy.getReturnType()->isIntegerTy(32));
|
|
|
|
case LibFunc_execvP:
|
|
|
|
case LibFunc_execvpe:
|
|
|
|
case LibFunc_execve:
|
|
|
|
return (NumParams == 3 && FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getParamType(1)->isPointerTy() &&
|
|
|
|
FTy.getParamType(2)->isPointerTy() &&
|
|
|
|
FTy.getReturnType()->isIntegerTy(32));
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_strlen:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 1 && FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getReturnType()->isIntegerTy());
|
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_strchr:
|
|
|
|
case LibFunc_strrchr:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 2 && FTy.getReturnType()->isPointerTy() &&
|
|
|
|
FTy.getParamType(0) == FTy.getReturnType() &&
|
|
|
|
FTy.getParamType(1)->isIntegerTy());
|
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_strtol:
|
|
|
|
case LibFunc_strtod:
|
|
|
|
case LibFunc_strtof:
|
|
|
|
case LibFunc_strtoul:
|
|
|
|
case LibFunc_strtoll:
|
|
|
|
case LibFunc_strtold:
|
|
|
|
case LibFunc_strtoull:
|
2016-04-28 03:04:35 +08:00
|
|
|
return ((NumParams == 2 || NumParams == 3) &&
|
|
|
|
FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getParamType(1)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_strcat:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 2 && FTy.getReturnType()->isPointerTy() &&
|
|
|
|
FTy.getParamType(0) == FTy.getReturnType() &&
|
|
|
|
FTy.getParamType(1) == FTy.getReturnType());
|
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_strncat:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 3 && FTy.getReturnType()->isPointerTy() &&
|
|
|
|
FTy.getParamType(0) == FTy.getReturnType() &&
|
|
|
|
FTy.getParamType(1) == FTy.getReturnType() &&
|
2017-12-18 18:31:58 +08:00
|
|
|
IsSizeTTy(FTy.getParamType(2)));
|
2016-04-28 03:04:35 +08:00
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_strcpy_chk:
|
|
|
|
case LibFunc_stpcpy_chk:
|
2016-04-28 03:04:35 +08:00
|
|
|
--NumParams;
|
|
|
|
if (!IsSizeTTy(FTy.getParamType(NumParams)))
|
|
|
|
return false;
|
2016-08-17 13:10:15 +08:00
|
|
|
LLVM_FALLTHROUGH;
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_strcpy:
|
|
|
|
case LibFunc_stpcpy:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 2 && FTy.getReturnType() == FTy.getParamType(0) &&
|
|
|
|
FTy.getParamType(0) == FTy.getParamType(1) &&
|
|
|
|
FTy.getParamType(0) == PCharTy);
|
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_strncpy_chk:
|
|
|
|
case LibFunc_stpncpy_chk:
|
2016-04-28 03:04:35 +08:00
|
|
|
--NumParams;
|
|
|
|
if (!IsSizeTTy(FTy.getParamType(NumParams)))
|
|
|
|
return false;
|
2016-08-17 13:10:15 +08:00
|
|
|
LLVM_FALLTHROUGH;
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_strncpy:
|
|
|
|
case LibFunc_stpncpy:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 3 && FTy.getReturnType() == FTy.getParamType(0) &&
|
|
|
|
FTy.getParamType(0) == FTy.getParamType(1) &&
|
|
|
|
FTy.getParamType(0) == PCharTy &&
|
2017-12-18 18:31:58 +08:00
|
|
|
IsSizeTTy(FTy.getParamType(2)));
|
2016-04-28 03:04:35 +08:00
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_strxfrm:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 3 && FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getParamType(1)->isPointerTy());
|
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_strcmp:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 2 && FTy.getReturnType()->isIntegerTy(32) &&
|
|
|
|
FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getParamType(0) == FTy.getParamType(1));
|
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_strncmp:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 3 && FTy.getReturnType()->isIntegerTy(32) &&
|
|
|
|
FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getParamType(0) == FTy.getParamType(1) &&
|
2017-12-18 18:31:58 +08:00
|
|
|
IsSizeTTy(FTy.getParamType(2)));
|
2016-04-28 03:04:35 +08:00
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_strspn:
|
|
|
|
case LibFunc_strcspn:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 2 && FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getParamType(0) == FTy.getParamType(1) &&
|
|
|
|
FTy.getReturnType()->isIntegerTy());
|
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_strcoll:
|
|
|
|
case LibFunc_strcasecmp:
|
|
|
|
case LibFunc_strncasecmp:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams >= 2 && FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getParamType(1)->isPointerTy());
|
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_strstr:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 2 && FTy.getReturnType()->isPointerTy() &&
|
|
|
|
FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getParamType(1)->isPointerTy());
|
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_strpbrk:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 2 && FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getReturnType() == FTy.getParamType(0) &&
|
|
|
|
FTy.getParamType(0) == FTy.getParamType(1));
|
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_strtok:
|
|
|
|
case LibFunc_strtok_r:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams >= 2 && FTy.getParamType(1)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_scanf:
|
|
|
|
case LibFunc_setbuf:
|
|
|
|
case LibFunc_setvbuf:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams >= 1 && FTy.getParamType(0)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_strdup:
|
|
|
|
case LibFunc_strndup:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams >= 1 && FTy.getReturnType()->isPointerTy() &&
|
|
|
|
FTy.getParamType(0)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_sscanf:
|
|
|
|
case LibFunc_stat:
|
|
|
|
case LibFunc_statvfs:
|
|
|
|
case LibFunc_siprintf:
|
|
|
|
case LibFunc_sprintf:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams >= 2 && FTy.getParamType(0)->isPointerTy() &&
|
2018-05-12 00:53:56 +08:00
|
|
|
FTy.getParamType(1)->isPointerTy() &&
|
|
|
|
FTy.getReturnType()->isIntegerTy(32));
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_snprintf:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 3 && FTy.getParamType(0)->isPointerTy() &&
|
2018-05-12 00:53:56 +08:00
|
|
|
FTy.getParamType(2)->isPointerTy() &&
|
|
|
|
FTy.getReturnType()->isIntegerTy(32));
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_setitimer:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 3 && FTy.getParamType(1)->isPointerTy() &&
|
|
|
|
FTy.getParamType(2)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_system:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 1 && FTy.getParamType(0)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_malloc:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 1 && FTy.getReturnType()->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_memcmp:
|
2017-01-17 11:10:02 +08:00
|
|
|
return (NumParams == 3 && FTy.getReturnType()->isIntegerTy(32) &&
|
|
|
|
FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getParamType(1)->isPointerTy());
|
2016-04-28 03:04:35 +08:00
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_memchr:
|
|
|
|
case LibFunc_memrchr:
|
2017-01-17 11:10:02 +08:00
|
|
|
return (NumParams == 3 && FTy.getReturnType()->isPointerTy() &&
|
|
|
|
FTy.getReturnType() == FTy.getParamType(0) &&
|
2016-04-28 03:04:35 +08:00
|
|
|
FTy.getParamType(1)->isIntegerTy(32) &&
|
2017-01-17 11:10:02 +08:00
|
|
|
IsSizeTTy(FTy.getParamType(2)));
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_modf:
|
|
|
|
case LibFunc_modff:
|
|
|
|
case LibFunc_modfl:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams >= 2 && FTy.getParamType(1)->isPointerTy());
|
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_memcpy_chk:
|
|
|
|
case LibFunc_memmove_chk:
|
2016-04-28 03:04:35 +08:00
|
|
|
--NumParams;
|
|
|
|
if (!IsSizeTTy(FTy.getParamType(NumParams)))
|
|
|
|
return false;
|
2016-08-17 13:10:15 +08:00
|
|
|
LLVM_FALLTHROUGH;
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_memcpy:
|
|
|
|
case LibFunc_mempcpy:
|
|
|
|
case LibFunc_memmove:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 3 && FTy.getReturnType() == FTy.getParamType(0) &&
|
|
|
|
FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getParamType(1)->isPointerTy() &&
|
|
|
|
IsSizeTTy(FTy.getParamType(2)));
|
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_memset_chk:
|
2016-04-28 03:04:35 +08:00
|
|
|
--NumParams;
|
|
|
|
if (!IsSizeTTy(FTy.getParamType(NumParams)))
|
|
|
|
return false;
|
2016-08-17 13:10:15 +08:00
|
|
|
LLVM_FALLTHROUGH;
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_memset:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 3 && FTy.getReturnType() == FTy.getParamType(0) &&
|
|
|
|
FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getParamType(1)->isIntegerTy() &&
|
|
|
|
IsSizeTTy(FTy.getParamType(2)));
|
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_memccpy:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams >= 2 && FTy.getParamType(1)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_memalign:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (FTy.getReturnType()->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_realloc:
|
|
|
|
case LibFunc_reallocf:
|
2017-01-17 11:10:02 +08:00
|
|
|
return (NumParams == 2 && FTy.getReturnType() == PCharTy &&
|
|
|
|
FTy.getParamType(0) == FTy.getReturnType() &&
|
|
|
|
IsSizeTTy(FTy.getParamType(1)));
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_read:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 3 && FTy.getParamType(1)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_rewind:
|
|
|
|
case LibFunc_rmdir:
|
|
|
|
case LibFunc_remove:
|
|
|
|
case LibFunc_realpath:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams >= 1 && FTy.getParamType(0)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_rename:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams >= 2 && FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getParamType(1)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_readlink:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams >= 2 && FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getParamType(1)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_write:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 3 && FTy.getParamType(1)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_bcopy:
|
|
|
|
case LibFunc_bcmp:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 3 && FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getParamType(1)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_bzero:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 2 && FTy.getParamType(0)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_calloc:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 2 && FTy.getReturnType()->isPointerTy());
|
2016-05-26 04:22:45 +08:00
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_atof:
|
|
|
|
case LibFunc_atoi:
|
|
|
|
case LibFunc_atol:
|
|
|
|
case LibFunc_atoll:
|
|
|
|
case LibFunc_ferror:
|
|
|
|
case LibFunc_getenv:
|
|
|
|
case LibFunc_getpwnam:
|
|
|
|
case LibFunc_iprintf:
|
|
|
|
case LibFunc_pclose:
|
|
|
|
case LibFunc_perror:
|
|
|
|
case LibFunc_printf:
|
|
|
|
case LibFunc_puts:
|
|
|
|
case LibFunc_uname:
|
|
|
|
case LibFunc_under_IO_getc:
|
|
|
|
case LibFunc_unlink:
|
|
|
|
case LibFunc_unsetenv:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 1 && FTy.getParamType(0)->isPointerTy());
|
2016-05-26 04:22:45 +08:00
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_access:
|
|
|
|
case LibFunc_chmod:
|
|
|
|
case LibFunc_chown:
|
|
|
|
case LibFunc_clearerr:
|
|
|
|
case LibFunc_closedir:
|
|
|
|
case LibFunc_ctermid:
|
|
|
|
case LibFunc_fclose:
|
|
|
|
case LibFunc_feof:
|
|
|
|
case LibFunc_fflush:
|
|
|
|
case LibFunc_fgetc:
|
[SimplifyLibcalls] Replace locked IO with unlocked IO
Summary: If file stream arg is not captured and source is fopen, we could replace IO calls by unlocked IO ("_unlocked" function variants) to gain better speed,
Reviewers: efriedma, RKSimon, spatel, sanjoy, hfinkel, majnemer, lebedev.ri, rja
Reviewed By: rja
Subscribers: rja, srhines, efriedma, lebedev.ri, llvm-commits
Differential Revision: https://reviews.llvm.org/D45736
llvm-svn: 332452
2018-05-16 19:39:52 +08:00
|
|
|
case LibFunc_fgetc_unlocked:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_fileno:
|
|
|
|
case LibFunc_flockfile:
|
|
|
|
case LibFunc_free:
|
|
|
|
case LibFunc_fseek:
|
|
|
|
case LibFunc_fseeko64:
|
|
|
|
case LibFunc_fseeko:
|
|
|
|
case LibFunc_fsetpos:
|
|
|
|
case LibFunc_ftell:
|
|
|
|
case LibFunc_ftello64:
|
|
|
|
case LibFunc_ftello:
|
|
|
|
case LibFunc_ftrylockfile:
|
|
|
|
case LibFunc_funlockfile:
|
|
|
|
case LibFunc_getc:
|
|
|
|
case LibFunc_getc_unlocked:
|
|
|
|
case LibFunc_getlogin_r:
|
|
|
|
case LibFunc_mkdir:
|
|
|
|
case LibFunc_mktime:
|
|
|
|
case LibFunc_times:
|
2016-05-26 04:22:45 +08:00
|
|
|
return (NumParams != 0 && FTy.getParamType(0)->isPointerTy());
|
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_fopen:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 2 && FTy.getReturnType()->isPointerTy() &&
|
|
|
|
FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getParamType(1)->isPointerTy());
|
2018-11-07 21:49:17 +08:00
|
|
|
case LibFunc_fork:
|
|
|
|
return (NumParams == 0 && FTy.getReturnType()->isIntegerTy(32));
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_fdopen:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 2 && FTy.getReturnType()->isPointerTy() &&
|
|
|
|
FTy.getParamType(1)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_fputc:
|
[SimplifyLibcalls] Replace locked IO with unlocked IO
Summary: If file stream arg is not captured and source is fopen, we could replace IO calls by unlocked IO ("_unlocked" function variants) to gain better speed,
Reviewers: efriedma, RKSimon, spatel, sanjoy, hfinkel, majnemer, lebedev.ri, rja
Reviewed By: rja
Subscribers: rja, srhines, efriedma, lebedev.ri, llvm-commits
Differential Revision: https://reviews.llvm.org/D45736
llvm-svn: 332452
2018-05-16 19:39:52 +08:00
|
|
|
case LibFunc_fputc_unlocked:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_fstat:
|
|
|
|
case LibFunc_frexp:
|
|
|
|
case LibFunc_frexpf:
|
|
|
|
case LibFunc_frexpl:
|
|
|
|
case LibFunc_fstatvfs:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 2 && FTy.getParamType(1)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_fgets:
|
[SimplifyLibcalls] Replace locked IO with unlocked IO
Summary: If file stream arg is not captured and source is fopen, we could replace IO calls by unlocked IO ("_unlocked" function variants) to gain better speed,
Reviewers: efriedma, RKSimon, spatel, sanjoy, hfinkel, majnemer, lebedev.ri, rja
Reviewed By: rja
Subscribers: rja, srhines, efriedma, lebedev.ri, llvm-commits
Differential Revision: https://reviews.llvm.org/D45736
llvm-svn: 332452
2018-05-16 19:39:52 +08:00
|
|
|
case LibFunc_fgets_unlocked:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 3 && FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getParamType(2)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_fread:
|
[SimplifyLibcalls] Replace locked IO with unlocked IO
Summary: If file stream arg is not captured and source is fopen, we could replace IO calls by unlocked IO ("_unlocked" function variants) to gain better speed,
Reviewers: efriedma, RKSimon, spatel, sanjoy, hfinkel, majnemer, lebedev.ri, rja
Reviewed By: rja
Subscribers: rja, srhines, efriedma, lebedev.ri, llvm-commits
Differential Revision: https://reviews.llvm.org/D45736
llvm-svn: 332452
2018-05-16 19:39:52 +08:00
|
|
|
case LibFunc_fread_unlocked:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 4 && FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getParamType(3)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_fwrite:
|
[SimplifyLibcalls] Replace locked IO with unlocked IO
Summary: If file stream arg is not captured and source is fopen, we could replace IO calls by unlocked IO ("_unlocked" function variants) to gain better speed,
Reviewers: efriedma, RKSimon, spatel, sanjoy, hfinkel, majnemer, lebedev.ri, rja
Reviewed By: rja
Subscribers: rja, srhines, efriedma, lebedev.ri, llvm-commits
Differential Revision: https://reviews.llvm.org/D45736
llvm-svn: 332452
2018-05-16 19:39:52 +08:00
|
|
|
case LibFunc_fwrite_unlocked:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 4 && FTy.getReturnType()->isIntegerTy() &&
|
|
|
|
FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getParamType(1)->isIntegerTy() &&
|
|
|
|
FTy.getParamType(2)->isIntegerTy() &&
|
|
|
|
FTy.getParamType(3)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_fputs:
|
[SimplifyLibcalls] Replace locked IO with unlocked IO
Summary: If file stream arg is not captured and source is fopen, we could replace IO calls by unlocked IO ("_unlocked" function variants) to gain better speed,
Reviewers: efriedma, RKSimon, spatel, sanjoy, hfinkel, majnemer, lebedev.ri, rja
Reviewed By: rja
Subscribers: rja, srhines, efriedma, lebedev.ri, llvm-commits
Differential Revision: https://reviews.llvm.org/D45736
llvm-svn: 332452
2018-05-16 19:39:52 +08:00
|
|
|
case LibFunc_fputs_unlocked:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams >= 2 && FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getParamType(1)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_fscanf:
|
|
|
|
case LibFunc_fiprintf:
|
|
|
|
case LibFunc_fprintf:
|
2017-01-17 11:10:02 +08:00
|
|
|
return (NumParams >= 2 && FTy.getReturnType()->isIntegerTy() &&
|
|
|
|
FTy.getParamType(0)->isPointerTy() &&
|
2016-04-28 03:04:35 +08:00
|
|
|
FTy.getParamType(1)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_fgetpos:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams >= 2 && FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getParamType(1)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_getchar:
|
[SimplifyLibcalls] Replace locked IO with unlocked IO
Summary: If file stream arg is not captured and source is fopen, we could replace IO calls by unlocked IO ("_unlocked" function variants) to gain better speed,
Reviewers: efriedma, RKSimon, spatel, sanjoy, hfinkel, majnemer, lebedev.ri, rja
Reviewed By: rja
Subscribers: rja, srhines, efriedma, lebedev.ri, llvm-commits
Differential Revision: https://reviews.llvm.org/D45736
llvm-svn: 332452
2018-05-16 19:39:52 +08:00
|
|
|
case LibFunc_getchar_unlocked:
|
2017-01-17 11:10:02 +08:00
|
|
|
return (NumParams == 0 && FTy.getReturnType()->isIntegerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_gets:
|
2017-01-17 11:10:02 +08:00
|
|
|
return (NumParams == 1 && FTy.getParamType(0) == PCharTy);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_getitimer:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 2 && FTy.getParamType(1)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_ungetc:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 2 && FTy.getParamType(1)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_utime:
|
|
|
|
case LibFunc_utimes:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 2 && FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getParamType(1)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_putc:
|
[SimplifyLibcalls] Replace locked IO with unlocked IO
Summary: If file stream arg is not captured and source is fopen, we could replace IO calls by unlocked IO ("_unlocked" function variants) to gain better speed,
Reviewers: efriedma, RKSimon, spatel, sanjoy, hfinkel, majnemer, lebedev.ri, rja
Reviewed By: rja
Subscribers: rja, srhines, efriedma, lebedev.ri, llvm-commits
Differential Revision: https://reviews.llvm.org/D45736
llvm-svn: 332452
2018-05-16 19:39:52 +08:00
|
|
|
case LibFunc_putc_unlocked:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 2 && FTy.getParamType(1)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_pread:
|
|
|
|
case LibFunc_pwrite:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 4 && FTy.getParamType(1)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_popen:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 2 && FTy.getReturnType()->isPointerTy() &&
|
|
|
|
FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getParamType(1)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_vscanf:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 2 && FTy.getParamType(1)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_vsscanf:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 3 && FTy.getParamType(1)->isPointerTy() &&
|
|
|
|
FTy.getParamType(2)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_vfscanf:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 3 && FTy.getParamType(1)->isPointerTy() &&
|
|
|
|
FTy.getParamType(2)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_valloc:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (FTy.getReturnType()->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_vprintf:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 2 && FTy.getParamType(0)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_vfprintf:
|
|
|
|
case LibFunc_vsprintf:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 3 && FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getParamType(1)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_vsnprintf:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 4 && FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getParamType(2)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_open:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams >= 2 && FTy.getParamType(0)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_opendir:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 1 && FTy.getReturnType()->isPointerTy() &&
|
|
|
|
FTy.getParamType(0)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_tmpfile:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (FTy.getReturnType()->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_htonl:
|
|
|
|
case LibFunc_ntohl:
|
2017-01-17 11:10:02 +08:00
|
|
|
return (NumParams == 1 && FTy.getReturnType()->isIntegerTy(32) &&
|
|
|
|
FTy.getReturnType() == FTy.getParamType(0));
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_htons:
|
|
|
|
case LibFunc_ntohs:
|
2017-01-17 11:10:02 +08:00
|
|
|
return (NumParams == 1 && FTy.getReturnType()->isIntegerTy(16) &&
|
|
|
|
FTy.getReturnType() == FTy.getParamType(0));
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_lstat:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 2 && FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getParamType(1)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_lchown:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 3 && FTy.getParamType(0)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_qsort:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 4 && FTy.getParamType(3)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_dunder_strdup:
|
|
|
|
case LibFunc_dunder_strndup:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams >= 1 && FTy.getReturnType()->isPointerTy() &&
|
|
|
|
FTy.getParamType(0)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_dunder_strtok_r:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 3 && FTy.getParamType(1)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_under_IO_putc:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 2 && FTy.getParamType(1)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_dunder_isoc99_scanf:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams >= 1 && FTy.getParamType(0)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_stat64:
|
|
|
|
case LibFunc_lstat64:
|
|
|
|
case LibFunc_statvfs64:
|
2016-09-21 07:10:31 +08:00
|
|
|
return (NumParams == 2 && FTy.getParamType(0)->isPointerTy() &&
|
2016-04-28 03:04:35 +08:00
|
|
|
FTy.getParamType(1)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_dunder_isoc99_sscanf:
|
2016-09-21 07:10:31 +08:00
|
|
|
return (NumParams >= 2 && FTy.getParamType(0)->isPointerTy() &&
|
2016-04-28 03:04:35 +08:00
|
|
|
FTy.getParamType(1)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_fopen64:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 2 && FTy.getReturnType()->isPointerTy() &&
|
|
|
|
FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getParamType(1)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_tmpfile64:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (FTy.getReturnType()->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_fstat64:
|
|
|
|
case LibFunc_fstatvfs64:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 2 && FTy.getParamType(1)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_open64:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams >= 2 && FTy.getParamType(0)->isPointerTy());
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_gettimeofday:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 2 && FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getParamType(1)->isPointerTy());
|
|
|
|
|
2017-01-17 11:10:02 +08:00
|
|
|
// new(unsigned int);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_Znwj:
|
2017-01-17 11:10:02 +08:00
|
|
|
// new(unsigned long);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_Znwm:
|
2017-01-17 11:10:02 +08:00
|
|
|
// new[](unsigned int);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_Znaj:
|
2017-01-17 11:10:02 +08:00
|
|
|
// new[](unsigned long);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_Znam:
|
2017-01-17 11:10:02 +08:00
|
|
|
// new(unsigned int);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_msvc_new_int:
|
2017-01-17 11:10:02 +08:00
|
|
|
// new(unsigned long long);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_msvc_new_longlong:
|
2017-01-17 11:10:02 +08:00
|
|
|
// new[](unsigned int);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_msvc_new_array_int:
|
2017-01-17 11:10:02 +08:00
|
|
|
// new[](unsigned long long);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_msvc_new_array_longlong:
|
2017-01-17 11:10:02 +08:00
|
|
|
return (NumParams == 1 && FTy.getReturnType()->isPointerTy());
|
|
|
|
|
|
|
|
// new(unsigned int, nothrow);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_ZnwjRKSt9nothrow_t:
|
2017-01-17 11:10:02 +08:00
|
|
|
// new(unsigned long, nothrow);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_ZnwmRKSt9nothrow_t:
|
2017-01-17 11:10:02 +08:00
|
|
|
// new[](unsigned int, nothrow);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_ZnajRKSt9nothrow_t:
|
2017-01-17 11:10:02 +08:00
|
|
|
// new[](unsigned long, nothrow);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_ZnamRKSt9nothrow_t:
|
2017-01-17 11:10:02 +08:00
|
|
|
// new(unsigned int, nothrow);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_msvc_new_int_nothrow:
|
2017-01-17 11:10:02 +08:00
|
|
|
// new(unsigned long long, nothrow);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_msvc_new_longlong_nothrow:
|
2017-01-17 11:10:02 +08:00
|
|
|
// new[](unsigned int, nothrow);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_msvc_new_array_int_nothrow:
|
2017-01-17 11:10:02 +08:00
|
|
|
// new[](unsigned long long, nothrow);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_msvc_new_array_longlong_nothrow:
|
2018-04-05 03:01:51 +08:00
|
|
|
// new(unsigned int, align_val_t)
|
|
|
|
case LibFunc_ZnwjSt11align_val_t:
|
|
|
|
// new(unsigned long, align_val_t)
|
|
|
|
case LibFunc_ZnwmSt11align_val_t:
|
|
|
|
// new[](unsigned int, align_val_t)
|
|
|
|
case LibFunc_ZnajSt11align_val_t:
|
|
|
|
// new[](unsigned long, align_val_t)
|
|
|
|
case LibFunc_ZnamSt11align_val_t:
|
2017-01-17 11:10:02 +08:00
|
|
|
return (NumParams == 2 && FTy.getReturnType()->isPointerTy());
|
|
|
|
|
2018-04-05 03:01:51 +08:00
|
|
|
// new(unsigned int, align_val_t, nothrow)
|
|
|
|
case LibFunc_ZnwjSt11align_val_tRKSt9nothrow_t:
|
|
|
|
// new(unsigned long, align_val_t, nothrow)
|
|
|
|
case LibFunc_ZnwmSt11align_val_tRKSt9nothrow_t:
|
|
|
|
// new[](unsigned int, align_val_t, nothrow)
|
|
|
|
case LibFunc_ZnajSt11align_val_tRKSt9nothrow_t:
|
|
|
|
// new[](unsigned long, align_val_t, nothrow)
|
|
|
|
case LibFunc_ZnamSt11align_val_tRKSt9nothrow_t:
|
|
|
|
return (NumParams == 3 && FTy.getReturnType()->isPointerTy());
|
|
|
|
|
2017-01-17 11:10:02 +08:00
|
|
|
// void operator delete[](void*);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_ZdaPv:
|
2017-01-17 11:10:02 +08:00
|
|
|
// void operator delete(void*);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_ZdlPv:
|
2017-01-17 11:10:02 +08:00
|
|
|
// void operator delete[](void*);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_msvc_delete_array_ptr32:
|
2017-01-17 11:10:02 +08:00
|
|
|
// void operator delete[](void*);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_msvc_delete_array_ptr64:
|
2017-01-17 11:10:02 +08:00
|
|
|
// void operator delete(void*);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_msvc_delete_ptr32:
|
2017-01-17 11:10:02 +08:00
|
|
|
// void operator delete(void*);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_msvc_delete_ptr64:
|
2017-01-17 11:10:02 +08:00
|
|
|
return (NumParams == 1 && FTy.getParamType(0)->isPointerTy());
|
|
|
|
|
|
|
|
// void operator delete[](void*, nothrow);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_ZdaPvRKSt9nothrow_t:
|
2017-01-17 11:10:02 +08:00
|
|
|
// void operator delete[](void*, unsigned int);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_ZdaPvj:
|
2017-01-17 11:10:02 +08:00
|
|
|
// void operator delete[](void*, unsigned long);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_ZdaPvm:
|
2017-01-17 11:10:02 +08:00
|
|
|
// void operator delete(void*, nothrow);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_ZdlPvRKSt9nothrow_t:
|
2017-01-17 11:10:02 +08:00
|
|
|
// void operator delete(void*, unsigned int);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_ZdlPvj:
|
2017-01-17 11:10:02 +08:00
|
|
|
// void operator delete(void*, unsigned long);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_ZdlPvm:
|
2018-04-05 03:01:51 +08:00
|
|
|
// void operator delete(void*, align_val_t)
|
|
|
|
case LibFunc_ZdlPvSt11align_val_t:
|
|
|
|
// void operator delete[](void*, align_val_t)
|
|
|
|
case LibFunc_ZdaPvSt11align_val_t:
|
2017-01-17 11:10:02 +08:00
|
|
|
// void operator delete[](void*, unsigned int);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_msvc_delete_array_ptr32_int:
|
2017-01-17 11:10:02 +08:00
|
|
|
// void operator delete[](void*, nothrow);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_msvc_delete_array_ptr32_nothrow:
|
2017-01-17 11:10:02 +08:00
|
|
|
// void operator delete[](void*, unsigned long long);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_msvc_delete_array_ptr64_longlong:
|
2017-01-17 11:10:02 +08:00
|
|
|
// void operator delete[](void*, nothrow);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_msvc_delete_array_ptr64_nothrow:
|
2017-01-17 11:10:02 +08:00
|
|
|
// void operator delete(void*, unsigned int);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_msvc_delete_ptr32_int:
|
2017-01-17 11:10:02 +08:00
|
|
|
// void operator delete(void*, nothrow);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_msvc_delete_ptr32_nothrow:
|
2017-01-17 11:10:02 +08:00
|
|
|
// void operator delete(void*, unsigned long long);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_msvc_delete_ptr64_longlong:
|
2017-01-17 11:10:02 +08:00
|
|
|
// void operator delete(void*, nothrow);
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_msvc_delete_ptr64_nothrow:
|
2017-01-17 11:10:02 +08:00
|
|
|
return (NumParams == 2 && FTy.getParamType(0)->isPointerTy());
|
2016-04-28 03:04:35 +08:00
|
|
|
|
2018-04-05 03:01:51 +08:00
|
|
|
// void operator delete(void*, align_val_t, nothrow)
|
|
|
|
case LibFunc_ZdlPvSt11align_val_tRKSt9nothrow_t:
|
|
|
|
// void operator delete[](void*, align_val_t, nothrow)
|
|
|
|
case LibFunc_ZdaPvSt11align_val_tRKSt9nothrow_t:
|
|
|
|
return (NumParams == 3 && FTy.getParamType(0)->isPointerTy());
|
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_memset_pattern16:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (!FTy.isVarArg() && NumParams == 3 &&
|
2017-01-17 11:10:02 +08:00
|
|
|
FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getParamType(1)->isPointerTy() &&
|
|
|
|
FTy.getParamType(2)->isIntegerTy());
|
2016-04-28 03:04:35 +08:00
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_cxa_guard_abort:
|
|
|
|
case LibFunc_cxa_guard_acquire:
|
|
|
|
case LibFunc_cxa_guard_release:
|
|
|
|
case LibFunc_nvvm_reflect:
|
2017-01-17 11:10:02 +08:00
|
|
|
return (NumParams == 1 && FTy.getParamType(0)->isPointerTy());
|
2016-04-28 03:04:35 +08:00
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_sincospi_stret:
|
|
|
|
case LibFunc_sincospif_stret:
|
2017-01-17 11:10:02 +08:00
|
|
|
return (NumParams == 1 && FTy.getParamType(0)->isFloatingPointTy());
|
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_acos:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_acos_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_acosf:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_acosf_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_acosh:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_acosh_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_acoshf:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_acoshf_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_acoshl:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_acoshl_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_acosl:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_acosl_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_asin:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_asin_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_asinf:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_asinf_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_asinh:
|
|
|
|
case LibFunc_asinhf:
|
|
|
|
case LibFunc_asinhl:
|
|
|
|
case LibFunc_asinl:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_asinl_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_atan:
|
|
|
|
case LibFunc_atanf:
|
|
|
|
case LibFunc_atanh:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_atanh_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_atanhf:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_atanhf_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_atanhl:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_atanhl_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_atanl:
|
|
|
|
case LibFunc_cbrt:
|
|
|
|
case LibFunc_cbrtf:
|
|
|
|
case LibFunc_cbrtl:
|
|
|
|
case LibFunc_ceil:
|
|
|
|
case LibFunc_ceilf:
|
|
|
|
case LibFunc_ceill:
|
|
|
|
case LibFunc_cos:
|
|
|
|
case LibFunc_cosf:
|
|
|
|
case LibFunc_cosh:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_cosh_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_coshf:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_coshf_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_coshl:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_coshl_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_cosl:
|
|
|
|
case LibFunc_exp10:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_exp10_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_exp10f:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_exp10f_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_exp10l:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_exp10l_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_exp2:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_exp2_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_exp2f:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_exp2f_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_exp2l:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_exp2l_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_exp:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_exp_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_expf:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_expf_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_expl:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_expl_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_expm1:
|
|
|
|
case LibFunc_expm1f:
|
|
|
|
case LibFunc_expm1l:
|
|
|
|
case LibFunc_fabs:
|
|
|
|
case LibFunc_fabsf:
|
|
|
|
case LibFunc_fabsl:
|
|
|
|
case LibFunc_floor:
|
|
|
|
case LibFunc_floorf:
|
|
|
|
case LibFunc_floorl:
|
|
|
|
case LibFunc_log10:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_log10_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_log10f:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_log10f_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_log10l:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_log10l_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_log1p:
|
|
|
|
case LibFunc_log1pf:
|
|
|
|
case LibFunc_log1pl:
|
|
|
|
case LibFunc_log2:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_log2_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_log2f:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_log2f_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_log2l:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_log2l_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_log:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_log_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_logb:
|
|
|
|
case LibFunc_logbf:
|
|
|
|
case LibFunc_logbl:
|
|
|
|
case LibFunc_logf:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_logf_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_logl:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_logl_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_nearbyint:
|
|
|
|
case LibFunc_nearbyintf:
|
|
|
|
case LibFunc_nearbyintl:
|
|
|
|
case LibFunc_rint:
|
|
|
|
case LibFunc_rintf:
|
|
|
|
case LibFunc_rintl:
|
|
|
|
case LibFunc_round:
|
|
|
|
case LibFunc_roundf:
|
|
|
|
case LibFunc_roundl:
|
|
|
|
case LibFunc_sin:
|
|
|
|
case LibFunc_sinf:
|
|
|
|
case LibFunc_sinh:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_sinh_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_sinhf:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_sinhf_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_sinhl:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_sinhl_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_sinl:
|
|
|
|
case LibFunc_sqrt:
|
|
|
|
case LibFunc_sqrt_finite:
|
|
|
|
case LibFunc_sqrtf:
|
|
|
|
case LibFunc_sqrtf_finite:
|
|
|
|
case LibFunc_sqrtl:
|
|
|
|
case LibFunc_sqrtl_finite:
|
|
|
|
case LibFunc_tan:
|
|
|
|
case LibFunc_tanf:
|
|
|
|
case LibFunc_tanh:
|
|
|
|
case LibFunc_tanhf:
|
|
|
|
case LibFunc_tanhl:
|
|
|
|
case LibFunc_tanl:
|
|
|
|
case LibFunc_trunc:
|
|
|
|
case LibFunc_truncf:
|
|
|
|
case LibFunc_truncl:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 1 && FTy.getReturnType()->isFloatingPointTy() &&
|
|
|
|
FTy.getReturnType() == FTy.getParamType(0));
|
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_atan2:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_atan2_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_atan2f:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_atan2f_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_atan2l:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_atan2l_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_fmin:
|
|
|
|
case LibFunc_fminf:
|
|
|
|
case LibFunc_fminl:
|
|
|
|
case LibFunc_fmax:
|
|
|
|
case LibFunc_fmaxf:
|
|
|
|
case LibFunc_fmaxl:
|
|
|
|
case LibFunc_fmod:
|
|
|
|
case LibFunc_fmodf:
|
|
|
|
case LibFunc_fmodl:
|
|
|
|
case LibFunc_copysign:
|
|
|
|
case LibFunc_copysignf:
|
|
|
|
case LibFunc_copysignl:
|
|
|
|
case LibFunc_pow:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_pow_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_powf:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_powf_finite:
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_powl:
|
2017-05-13 06:11:12 +08:00
|
|
|
case LibFunc_powl_finite:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 2 && FTy.getReturnType()->isFloatingPointTy() &&
|
|
|
|
FTy.getReturnType() == FTy.getParamType(0) &&
|
|
|
|
FTy.getReturnType() == FTy.getParamType(1));
|
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_ldexp:
|
|
|
|
case LibFunc_ldexpf:
|
|
|
|
case LibFunc_ldexpl:
|
2017-01-17 11:10:02 +08:00
|
|
|
return (NumParams == 2 && FTy.getReturnType()->isFloatingPointTy() &&
|
|
|
|
FTy.getReturnType() == FTy.getParamType(0) &&
|
|
|
|
FTy.getParamType(1)->isIntegerTy(32));
|
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_ffs:
|
|
|
|
case LibFunc_ffsl:
|
|
|
|
case LibFunc_ffsll:
|
|
|
|
case LibFunc_fls:
|
|
|
|
case LibFunc_flsl:
|
|
|
|
case LibFunc_flsll:
|
2016-09-24 02:44:09 +08:00
|
|
|
return (NumParams == 1 && FTy.getReturnType()->isIntegerTy(32) &&
|
|
|
|
FTy.getParamType(0)->isIntegerTy());
|
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_isdigit:
|
|
|
|
case LibFunc_isascii:
|
|
|
|
case LibFunc_toascii:
|
|
|
|
case LibFunc_putchar:
|
[SimplifyLibcalls] Replace locked IO with unlocked IO
Summary: If file stream arg is not captured and source is fopen, we could replace IO calls by unlocked IO ("_unlocked" function variants) to gain better speed,
Reviewers: efriedma, RKSimon, spatel, sanjoy, hfinkel, majnemer, lebedev.ri, rja
Reviewed By: rja
Subscribers: rja, srhines, efriedma, lebedev.ri, llvm-commits
Differential Revision: https://reviews.llvm.org/D45736
llvm-svn: 332452
2018-05-16 19:39:52 +08:00
|
|
|
case LibFunc_putchar_unlocked:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 1 && FTy.getReturnType()->isIntegerTy(32) &&
|
2016-09-24 02:44:09 +08:00
|
|
|
FTy.getReturnType() == FTy.getParamType(0));
|
2016-04-28 03:04:35 +08:00
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_abs:
|
|
|
|
case LibFunc_labs:
|
|
|
|
case LibFunc_llabs:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 1 && FTy.getReturnType()->isIntegerTy() &&
|
|
|
|
FTy.getReturnType() == FTy.getParamType(0));
|
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_cxa_atexit:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 3 && FTy.getReturnType()->isIntegerTy() &&
|
|
|
|
FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getParamType(1)->isPointerTy() &&
|
|
|
|
FTy.getParamType(2)->isPointerTy());
|
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_sinpi:
|
|
|
|
case LibFunc_cospi:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 1 && FTy.getReturnType()->isDoubleTy() &&
|
|
|
|
FTy.getReturnType() == FTy.getParamType(0));
|
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_sinpif:
|
|
|
|
case LibFunc_cospif:
|
2016-04-28 03:04:35 +08:00
|
|
|
return (NumParams == 1 && FTy.getReturnType()->isFloatTy() &&
|
|
|
|
FTy.getReturnType() == FTy.getParamType(0));
|
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_strnlen:
|
2017-01-17 11:10:02 +08:00
|
|
|
return (NumParams == 2 && FTy.getReturnType() == FTy.getParamType(1) &&
|
|
|
|
FTy.getParamType(0) == PCharTy &&
|
|
|
|
FTy.getParamType(1) == SizeTTy);
|
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
case LibFunc_posix_memalign:
|
2017-01-17 11:10:02 +08:00
|
|
|
return (NumParams == 3 && FTy.getReturnType()->isIntegerTy(32) &&
|
|
|
|
FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getParamType(1) == SizeTTy && FTy.getParamType(2) == SizeTTy);
|
|
|
|
|
2017-05-06 04:25:50 +08:00
|
|
|
case LibFunc_wcslen:
|
|
|
|
return (NumParams == 1 && FTy.getParamType(0)->isPointerTy() &&
|
|
|
|
FTy.getReturnType()->isIntegerTy());
|
|
|
|
|
2017-12-16 09:26:25 +08:00
|
|
|
case LibFunc_cabs:
|
|
|
|
case LibFunc_cabsf:
|
|
|
|
case LibFunc_cabsl: {
|
|
|
|
Type* RetTy = FTy.getReturnType();
|
|
|
|
if (!RetTy->isFloatingPointTy())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// NOTE: These prototypes are target specific and currently support
|
|
|
|
// "complex" passed as an array or discrete real & imaginary parameters.
|
|
|
|
// Add other calling conventions to enable libcall optimizations.
|
|
|
|
if (NumParams == 1)
|
|
|
|
return (FTy.getParamType(0)->isArrayTy() &&
|
|
|
|
FTy.getParamType(0)->getArrayNumElements() == 2 &&
|
|
|
|
FTy.getParamType(0)->getArrayElementType() == RetTy);
|
|
|
|
else if (NumParams == 2)
|
|
|
|
return (FTy.getParamType(0) == RetTy && FTy.getParamType(1) == RetTy);
|
|
|
|
else
|
|
|
|
return false;
|
|
|
|
}
|
2017-01-17 11:10:02 +08:00
|
|
|
case LibFunc::NumLibFuncs:
|
2017-01-18 03:54:18 +08:00
|
|
|
break;
|
2016-04-28 03:04:35 +08:00
|
|
|
}
|
2017-01-17 11:10:02 +08:00
|
|
|
|
2017-01-18 03:54:18 +08:00
|
|
|
llvm_unreachable("Invalid libfunc");
|
2016-04-28 03:04:35 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
bool TargetLibraryInfoImpl::getLibFunc(const Function &FDecl,
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 07:16:46 +08:00
|
|
|
LibFunc &F) const {
|
2016-04-28 03:04:35 +08:00
|
|
|
const DataLayout *DL =
|
|
|
|
FDecl.getParent() ? &FDecl.getParent()->getDataLayout() : nullptr;
|
|
|
|
return getLibFunc(FDecl.getName(), F) &&
|
|
|
|
isValidProtoForLibFunc(*FDecl.getFunctionType(), F, DL);
|
|
|
|
}
|
|
|
|
|
[PM] Rework how the TargetLibraryInfo pass integrates with the new pass
manager to support the actual uses of it. =]
When I ported instcombine to the new pass manager I discover that it
didn't work because TLI wasn't available in the right places. This is
a somewhat surprising and/or subtle aspect of the new pass manager
design that came up before but I think is useful to be reminded of:
While the new pass manager *allows* a function pass to query a module
analysis, it requires that the module analysis is already run and cached
prior to the function pass manager starting up, possibly with
a 'require<foo>' style utility in the pass pipeline. This is an
intentional hurdle because using a module analysis from a function pass
*requires* that the module analysis is run prior to entering the
function pass manager. Otherwise the other functions in the module could
be in who-knows-what state, etc.
A somewhat surprising consequence of this design decision (at least to
me) is that you have to design a function pass that leverages
a module analysis to do so as an optional feature. Even if that means
your function pass does no work in the absence of the module analysis,
you have to handle that possibility and remain conservatively correct.
This is a natural consequence of things being able to invalidate the
module analysis and us being unable to re-run it. And it's a generally
good thing because it lets us reorder passes arbitrarily without
breaking correctness, etc.
This ends up causing problems in one case. What if we have a module
analysis that is *definitionally* impossible to invalidate. In the
places this might come up, the analysis is usually also definitionally
trivial to run even while other transformation passes run on the module,
regardless of the state of anything. And so, it follows that it is
natural to have a hard requirement on such analyses from a function
pass.
It turns out, that TargetLibraryInfo is just such an analysis, and
InstCombine has a hard requirement on it.
The approach I've taken here is to produce an analysis that models this
flexibility by making it both a module and a function analysis. This
exposes the fact that it is in fact safe to compute at any point. We can
even make it a valid CGSCC analysis at some point if that is useful.
However, we don't want to have a copy of the actual target library info
state for each function! This state is specific to the triple. The
somewhat direct and blunt approach here is to turn TLI into a pimpl,
with the state and mutators in the implementation class and the query
routines primarily in the wrapper. Then the analysis can lazily
construct and cache the implementations, keyed on the triple, and
on-demand produce wrappers of them for each function.
One minor annoyance is that we will end up with a wrapper for each
function in the module. While this is a bit wasteful (one pointer per
function) it seems tolerable. And it has the advantage of ensuring that
we pay the absolute minimum synchronization cost to access this
information should we end up with a nice parallel function pass manager
in the future. We could look into trying to mark when analysis results
are especially cheap to recompute and more eagerly GC-ing the cached
results, or we could look at supporting a variant of analyses whose
results are specifically *not* cached and expected to just be used and
discarded by the consumer. Either way, these seem like incremental
enhancements that should happen when we start profiling the memory and
CPU usage of the new pass manager and not before.
The other minor annoyance is that if we end up using the TLI in both
a module pass and a function pass, those will be produced by two
separate analyses, and thus will point to separate copies of the
implementation state. While a minor issue, I dislike this and would like
to find a way to cleanly allow a single analysis instance to be used
across multiple IR unit managers. But I don't have a good solution to
this today, and I don't want to hold up all of the work waiting to come
up with one. This too seems like a reasonable thing to incrementally
improve later.
llvm-svn: 226981
2015-01-24 10:06:09 +08:00
|
|
|
void TargetLibraryInfoImpl::disableAllFunctions() {
|
2011-02-19 06:34:03 +08:00
|
|
|
memset(AvailableArray, 0, sizeof(AvailableArray));
|
|
|
|
}
|
2015-01-15 18:41:28 +08:00
|
|
|
|
2015-03-18 03:22:30 +08:00
|
|
|
static bool compareByScalarFnName(const VecDesc &LHS, const VecDesc &RHS) {
|
2016-10-01 11:10:48 +08:00
|
|
|
return LHS.ScalarFnName < RHS.ScalarFnName;
|
2015-03-18 03:22:30 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static bool compareByVectorFnName(const VecDesc &LHS, const VecDesc &RHS) {
|
2016-10-01 11:10:48 +08:00
|
|
|
return LHS.VectorFnName < RHS.VectorFnName;
|
2015-03-18 03:22:30 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static bool compareWithScalarFnName(const VecDesc &LHS, StringRef S) {
|
2016-10-01 11:10:48 +08:00
|
|
|
return LHS.ScalarFnName < S;
|
2015-03-18 03:22:30 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static bool compareWithVectorFnName(const VecDesc &LHS, StringRef S) {
|
2016-10-01 11:10:48 +08:00
|
|
|
return LHS.VectorFnName < S;
|
2015-03-18 03:22:30 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void TargetLibraryInfoImpl::addVectorizableFunctions(ArrayRef<VecDesc> Fns) {
|
|
|
|
VectorDescs.insert(VectorDescs.end(), Fns.begin(), Fns.end());
|
llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)
Summary: The convenience wrapper in STLExtras is available since rL342102.
Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb
Subscribers: MatzeB, sanjoy, arsenm, dschuff, mehdi_amini, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, javed.absar, gbedwell, jrtc27, mgrang, atanasyan, steven_wu, george.burgess.iv, dexonsmith, kristina, jsji, llvm-commits
Differential Revision: https://reviews.llvm.org/D52573
llvm-svn: 343163
2018-09-27 10:13:45 +08:00
|
|
|
llvm::sort(VectorDescs, compareByScalarFnName);
|
2015-03-18 03:22:30 +08:00
|
|
|
|
|
|
|
ScalarDescs.insert(ScalarDescs.end(), Fns.begin(), Fns.end());
|
llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)
Summary: The convenience wrapper in STLExtras is available since rL342102.
Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb
Subscribers: MatzeB, sanjoy, arsenm, dschuff, mehdi_amini, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, javed.absar, gbedwell, jrtc27, mgrang, atanasyan, steven_wu, george.burgess.iv, dexonsmith, kristina, jsji, llvm-commits
Differential Revision: https://reviews.llvm.org/D52573
llvm-svn: 343163
2018-09-27 10:13:45 +08:00
|
|
|
llvm::sort(ScalarDescs, compareByVectorFnName);
|
2015-03-18 03:22:30 +08:00
|
|
|
}
|
|
|
|
|
2015-03-18 03:50:55 +08:00
|
|
|
void TargetLibraryInfoImpl::addVectorizableFunctionsFromVecLib(
|
|
|
|
enum VectorLibrary VecLib) {
|
|
|
|
switch (VecLib) {
|
|
|
|
case Accelerate: {
|
|
|
|
const VecDesc VecFuncs[] = {
|
2015-05-08 01:11:51 +08:00
|
|
|
// Floating-Point Arithmetic and Auxiliary Functions
|
|
|
|
{"ceilf", "vceilf", 4},
|
|
|
|
{"fabsf", "vfabsf", 4},
|
|
|
|
{"llvm.fabs.f32", "vfabsf", 4},
|
|
|
|
{"floorf", "vfloorf", 4},
|
|
|
|
{"sqrtf", "vsqrtf", 4},
|
|
|
|
{"llvm.sqrt.f32", "vsqrtf", 4},
|
|
|
|
|
|
|
|
// Exponential and Logarithmic Functions
|
2015-03-18 03:50:55 +08:00
|
|
|
{"expf", "vexpf", 4},
|
|
|
|
{"llvm.exp.f32", "vexpf", 4},
|
2015-05-08 01:11:51 +08:00
|
|
|
{"expm1f", "vexpm1f", 4},
|
2015-03-18 03:50:55 +08:00
|
|
|
{"logf", "vlogf", 4},
|
|
|
|
{"llvm.log.f32", "vlogf", 4},
|
2015-05-08 01:11:51 +08:00
|
|
|
{"log1pf", "vlog1pf", 4},
|
|
|
|
{"log10f", "vlog10f", 4},
|
|
|
|
{"llvm.log10.f32", "vlog10f", 4},
|
|
|
|
{"logbf", "vlogbf", 4},
|
|
|
|
|
|
|
|
// Trigonometric Functions
|
|
|
|
{"sinf", "vsinf", 4},
|
|
|
|
{"llvm.sin.f32", "vsinf", 4},
|
|
|
|
{"cosf", "vcosf", 4},
|
|
|
|
{"llvm.cos.f32", "vcosf", 4},
|
|
|
|
{"tanf", "vtanf", 4},
|
|
|
|
{"asinf", "vasinf", 4},
|
|
|
|
{"acosf", "vacosf", 4},
|
|
|
|
{"atanf", "vatanf", 4},
|
|
|
|
|
|
|
|
// Hyperbolic Functions
|
|
|
|
{"sinhf", "vsinhf", 4},
|
|
|
|
{"coshf", "vcoshf", 4},
|
|
|
|
{"tanhf", "vtanhf", 4},
|
|
|
|
{"asinhf", "vasinhf", 4},
|
|
|
|
{"acoshf", "vacoshf", 4},
|
|
|
|
{"atanhf", "vatanhf", 4},
|
2015-03-18 03:50:55 +08:00
|
|
|
};
|
|
|
|
addVectorizableFunctions(VecFuncs);
|
|
|
|
break;
|
|
|
|
}
|
2016-07-30 00:42:44 +08:00
|
|
|
case SVML: {
|
|
|
|
const VecDesc VecFuncs[] = {
|
|
|
|
{"sin", "__svml_sin2", 2},
|
|
|
|
{"sin", "__svml_sin4", 4},
|
|
|
|
{"sin", "__svml_sin8", 8},
|
|
|
|
|
|
|
|
{"sinf", "__svml_sinf4", 4},
|
|
|
|
{"sinf", "__svml_sinf8", 8},
|
|
|
|
{"sinf", "__svml_sinf16", 16},
|
|
|
|
|
2018-06-08 02:21:24 +08:00
|
|
|
{"llvm.sin.f64", "__svml_sin2", 2},
|
|
|
|
{"llvm.sin.f64", "__svml_sin4", 4},
|
|
|
|
{"llvm.sin.f64", "__svml_sin8", 8},
|
|
|
|
|
|
|
|
{"llvm.sin.f32", "__svml_sinf4", 4},
|
|
|
|
{"llvm.sin.f32", "__svml_sinf8", 8},
|
|
|
|
{"llvm.sin.f32", "__svml_sinf16", 16},
|
|
|
|
|
2016-07-30 00:42:44 +08:00
|
|
|
{"cos", "__svml_cos2", 2},
|
|
|
|
{"cos", "__svml_cos4", 4},
|
|
|
|
{"cos", "__svml_cos8", 8},
|
|
|
|
|
|
|
|
{"cosf", "__svml_cosf4", 4},
|
|
|
|
{"cosf", "__svml_cosf8", 8},
|
|
|
|
{"cosf", "__svml_cosf16", 16},
|
|
|
|
|
2018-06-08 02:21:24 +08:00
|
|
|
{"llvm.cos.f64", "__svml_cos2", 2},
|
|
|
|
{"llvm.cos.f64", "__svml_cos4", 4},
|
|
|
|
{"llvm.cos.f64", "__svml_cos8", 8},
|
|
|
|
|
|
|
|
{"llvm.cos.f32", "__svml_cosf4", 4},
|
|
|
|
{"llvm.cos.f32", "__svml_cosf8", 8},
|
|
|
|
{"llvm.cos.f32", "__svml_cosf16", 16},
|
|
|
|
|
2016-07-30 00:42:44 +08:00
|
|
|
{"pow", "__svml_pow2", 2},
|
|
|
|
{"pow", "__svml_pow4", 4},
|
|
|
|
{"pow", "__svml_pow8", 8},
|
|
|
|
|
|
|
|
{"powf", "__svml_powf4", 4},
|
|
|
|
{"powf", "__svml_powf8", 8},
|
|
|
|
{"powf", "__svml_powf16", 16},
|
|
|
|
|
2017-05-13 06:11:26 +08:00
|
|
|
{ "__pow_finite", "__svml_pow2", 2 },
|
|
|
|
{ "__pow_finite", "__svml_pow4", 4 },
|
|
|
|
{ "__pow_finite", "__svml_pow8", 8 },
|
|
|
|
|
|
|
|
{ "__powf_finite", "__svml_powf4", 4 },
|
|
|
|
{ "__powf_finite", "__svml_powf8", 8 },
|
|
|
|
{ "__powf_finite", "__svml_powf16", 16 },
|
|
|
|
|
2016-07-30 00:42:44 +08:00
|
|
|
{"llvm.pow.f64", "__svml_pow2", 2},
|
|
|
|
{"llvm.pow.f64", "__svml_pow4", 4},
|
|
|
|
{"llvm.pow.f64", "__svml_pow8", 8},
|
|
|
|
|
|
|
|
{"llvm.pow.f32", "__svml_powf4", 4},
|
|
|
|
{"llvm.pow.f32", "__svml_powf8", 8},
|
|
|
|
{"llvm.pow.f32", "__svml_powf16", 16},
|
|
|
|
|
|
|
|
{"exp", "__svml_exp2", 2},
|
|
|
|
{"exp", "__svml_exp4", 4},
|
|
|
|
{"exp", "__svml_exp8", 8},
|
|
|
|
|
|
|
|
{"expf", "__svml_expf4", 4},
|
|
|
|
{"expf", "__svml_expf8", 8},
|
|
|
|
{"expf", "__svml_expf16", 16},
|
|
|
|
|
2017-05-13 06:11:26 +08:00
|
|
|
{ "__exp_finite", "__svml_exp2", 2 },
|
|
|
|
{ "__exp_finite", "__svml_exp4", 4 },
|
|
|
|
{ "__exp_finite", "__svml_exp8", 8 },
|
|
|
|
|
|
|
|
{ "__expf_finite", "__svml_expf4", 4 },
|
|
|
|
{ "__expf_finite", "__svml_expf8", 8 },
|
|
|
|
{ "__expf_finite", "__svml_expf16", 16 },
|
|
|
|
|
2016-07-30 00:42:44 +08:00
|
|
|
{"llvm.exp.f64", "__svml_exp2", 2},
|
|
|
|
{"llvm.exp.f64", "__svml_exp4", 4},
|
|
|
|
{"llvm.exp.f64", "__svml_exp8", 8},
|
|
|
|
|
|
|
|
{"llvm.exp.f32", "__svml_expf4", 4},
|
|
|
|
{"llvm.exp.f32", "__svml_expf8", 8},
|
|
|
|
{"llvm.exp.f32", "__svml_expf16", 16},
|
|
|
|
|
|
|
|
{"log", "__svml_log2", 2},
|
|
|
|
{"log", "__svml_log4", 4},
|
|
|
|
{"log", "__svml_log8", 8},
|
|
|
|
|
|
|
|
{"logf", "__svml_logf4", 4},
|
|
|
|
{"logf", "__svml_logf8", 8},
|
|
|
|
{"logf", "__svml_logf16", 16},
|
|
|
|
|
2017-05-13 06:11:26 +08:00
|
|
|
{ "__log_finite", "__svml_log2", 2 },
|
|
|
|
{ "__log_finite", "__svml_log4", 4 },
|
|
|
|
{ "__log_finite", "__svml_log8", 8 },
|
|
|
|
|
|
|
|
{ "__logf_finite", "__svml_logf4", 4 },
|
|
|
|
{ "__logf_finite", "__svml_logf8", 8 },
|
|
|
|
{ "__logf_finite", "__svml_logf16", 16 },
|
|
|
|
|
2016-07-30 00:42:44 +08:00
|
|
|
{"llvm.log.f64", "__svml_log2", 2},
|
|
|
|
{"llvm.log.f64", "__svml_log4", 4},
|
|
|
|
{"llvm.log.f64", "__svml_log8", 8},
|
|
|
|
|
|
|
|
{"llvm.log.f32", "__svml_logf4", 4},
|
|
|
|
{"llvm.log.f32", "__svml_logf8", 8},
|
|
|
|
{"llvm.log.f32", "__svml_logf16", 16},
|
|
|
|
};
|
|
|
|
addVectorizableFunctions(VecFuncs);
|
|
|
|
break;
|
|
|
|
}
|
2018-11-24 14:41:39 +08:00
|
|
|
case SLEEFGNUABI: {
|
|
|
|
if (TT.getArch() == llvm::Triple::aarch64 ||
|
|
|
|
TT.getArch() == llvm::Triple::aarch64_be) {
|
|
|
|
const VecDesc AArch64TwoAndFourLaneVecFuncs[] = {
|
|
|
|
{ "acos", "_ZGVnN2v_acos", 2 },
|
|
|
|
{ "acos", "_ZGVnN4v_acosf", 4 },
|
|
|
|
{ "acosf", "_ZGVnN4v_acosf", 4 },
|
|
|
|
{ "llvm.acos.f64", "_ZGVnN2v_acos", 2 },
|
|
|
|
{ "llvm.acos.f32", "_ZGVnN4v_acosf", 4 },
|
|
|
|
|
|
|
|
{ "asin", "_ZGVnN2v_asin", 2 },
|
|
|
|
{ "asin", "_ZGVnN4v_asinf", 4 },
|
|
|
|
{ "asinf", "_ZGVnN4v_asinf", 4 },
|
|
|
|
{ "llvm.asin.f64", "_ZGVnN2v_asin", 2 },
|
|
|
|
{ "llvm.asin.f32", "_ZGVnN4v_asinf", 4 },
|
|
|
|
|
|
|
|
{ "atan", "_ZGVnN2v_atan", 2 },
|
|
|
|
{ "atan", "_ZGVnN4v_atanf", 4 },
|
|
|
|
{ "atanf", "_ZGVnN4v_atanf", 4 },
|
|
|
|
{ "llvm.atan.f64", "_ZGVnN2v_atan", 2 },
|
|
|
|
{ "llvm.atan.f32", "_ZGVnN4v_atanf", 4 },
|
|
|
|
|
|
|
|
{ "atan2", "_ZGVnN2vv_atan2", 2 },
|
|
|
|
{ "atan2", "_ZGVnN4vv_atan2f", 4 },
|
|
|
|
{ "atan2f", "_ZGVnN4vv_atan2f", 4 },
|
|
|
|
{ "llvm.atan2.f64", "_ZGVnN2vv_atan2", 2 },
|
|
|
|
{ "llvm.atan2.f32", "_ZGVnN4vv_atan2f", 4 },
|
|
|
|
{ "llvm.atan2.v2f64", "_ZGVnN2vv_atan2", 2 },
|
|
|
|
{ "llvm.atan2.v4f32", "_ZGVnN4vv_atan2f", 4 },
|
|
|
|
|
|
|
|
{ "atanh", "_ZGVnN2v_atanh", 2 },
|
|
|
|
{ "atanh", "_ZGVnN4v_atanhf", 4 },
|
|
|
|
{ "atanhf", "_ZGVnN4v_atanhf", 4 },
|
|
|
|
{ "llvm.atanh.f64", "_ZGVnN2v_atanh", 2 },
|
|
|
|
{ "llvm.atanh.f32", "_ZGVnN4v_atanhf", 4 },
|
|
|
|
|
|
|
|
{ "cos", "_ZGVnN2v_cos", 2 },
|
|
|
|
{ "cos", "_ZGVnN4v_cosf", 4 },
|
|
|
|
{ "cosf", "_ZGVnN4v_cosf", 4 },
|
|
|
|
{ "llvm.cos.f64", "_ZGVnN2v_cos", 2 },
|
|
|
|
{ "llvm.cos.f32", "_ZGVnN4v_cosf", 4 },
|
|
|
|
|
|
|
|
{ "cosh", "_ZGVnN2v_cosh", 2 },
|
|
|
|
{ "cosh", "_ZGVnN4v_coshf", 4 },
|
|
|
|
{ "coshf", "_ZGVnN4v_coshf", 4 },
|
|
|
|
{ "llvm.cosh.f64", "_ZGVnN2v_cosh", 2 },
|
|
|
|
{ "llvm.cosh.f32", "_ZGVnN4v_coshf", 4 },
|
|
|
|
|
|
|
|
{ "exp", "_ZGVnN2v_exp", 2 },
|
|
|
|
{ "exp", "_ZGVnN4v_expf", 4 },
|
|
|
|
{ "expf", "_ZGVnN4v_expf", 4 },
|
|
|
|
{ "llvm.exp.f64", "_ZGVnN2v_exp", 2 },
|
|
|
|
{ "llvm.exp.f32", "_ZGVnN4v_expf", 4 },
|
|
|
|
{ "llvm.exp.v2f64", "_ZGVnN2v_exp", 2 },
|
|
|
|
{ "llvm.exp.v4f32", "_ZGVnN4v_expf", 4 },
|
|
|
|
|
|
|
|
{ "exp2", "_ZGVnN2v_exp2", 2 },
|
|
|
|
{ "exp2", "_ZGVnN4v_exp2f", 4 },
|
|
|
|
{ "exp2f", "_ZGVnN4v_exp2f", 4 },
|
|
|
|
{ "llvm.exp2.f64", "_ZGVnN2v_exp2", 2 },
|
|
|
|
{ "llvm.exp2.f32", "_ZGVnN4v_exp2f", 4 },
|
|
|
|
{ "llvm.exp2.v2f64", "_ZGVnN2v_exp2", 2 },
|
|
|
|
{ "llvm.exp2.v4f32", "_ZGVnN4v_exp2f", 4 },
|
|
|
|
|
|
|
|
{ "exp10", "_ZGVnN2v_exp10", 2 },
|
|
|
|
{ "exp10", "_ZGVnN4v_exp10f", 4 },
|
|
|
|
{ "exp10f", "_ZGVnN4v_exp10f", 4 },
|
|
|
|
{ "llvm.exp10.f64", "_ZGVnN2v_exp10", 2 },
|
|
|
|
{ "llvm.exp10.f32", "_ZGVnN4v_exp10f", 4 },
|
|
|
|
{ "llvm.exp10.v2f64", "_ZGVnN2v_exp10", 2 },
|
|
|
|
{ "llvm.exp10.v4f32", "_ZGVnN4v_exp10f", 4 },
|
|
|
|
|
|
|
|
{ "lgamma", "_ZGVnN2v_lgamma", 2 },
|
|
|
|
{ "lgamma", "_ZGVnN4v_lgammaf", 4 },
|
|
|
|
{ "lgammaf", "_ZGVnN4v_lgammaf", 4 },
|
|
|
|
{ "llvm.lgamma.f64", "_ZGVnN2v_lgamma", 2 },
|
|
|
|
{ "llvm.lgamma.f32", "_ZGVnN4v_lgammaf", 4 },
|
|
|
|
|
|
|
|
{ "log", "_ZGVnN2v_log", 2 },
|
|
|
|
{ "log", "_ZGVnN4v_logf", 4 },
|
|
|
|
{ "logf", "_ZGVnN4v_logf", 4 },
|
|
|
|
{ "llvm.log.f64", "_ZGVnN2v_log", 2 },
|
|
|
|
{ "llvm.log.f32", "_ZGVnN4v_logf", 4 },
|
|
|
|
|
|
|
|
{ "log2", "_ZGVnN2v_log2", 2 },
|
|
|
|
{ "log2", "_ZGVnN4v_log2f", 4 },
|
|
|
|
{ "log2f", "_ZGVnN4v_log2f", 4 },
|
|
|
|
{ "llvm.log2.f64", "_ZGVnN2v_log2", 2 },
|
|
|
|
{ "llvm.log2.f32", "_ZGVnN4v_log2f", 4 },
|
|
|
|
|
|
|
|
{ "log10", "_ZGVnN2v_log10", 2 },
|
|
|
|
{ "log10", "_ZGVnN4v_log10f", 4 },
|
|
|
|
{ "log10f", "_ZGVnN4v_log10f", 4 },
|
|
|
|
{ "llvm.log10.f64", "_ZGVnN2v_log10", 2 },
|
|
|
|
{ "llvm.log10.f32", "_ZGVnN4v_log10f", 4 },
|
|
|
|
|
|
|
|
{ "pow", "_ZGVnN2vv_pow", 2 },
|
|
|
|
{ "pow", "_ZGVnN4vv_powf", 4 },
|
|
|
|
{ "powf", "_ZGVnN4vv_powf", 4 },
|
|
|
|
{ "llvm.pow.f64", "_ZGVnN2vv_pow", 2 },
|
|
|
|
{ "llvm.pow.f32", "_ZGVnN4vv_powf", 4 },
|
|
|
|
{ "llvm.pow.v2f64", "_ZGVnN2vv_pow", 2 },
|
|
|
|
{ "llvm.pow.v4f32", "_ZGVnN4vv_powf", 4 },
|
|
|
|
|
|
|
|
{ "sin", "_ZGVnN2v_sin", 2 },
|
|
|
|
{ "sin", "_ZGVnN4v_sinf", 4 },
|
|
|
|
{ "sinf", "_ZGVnN4v_sinf", 4 },
|
|
|
|
{ "llvm.sin.f64", "_ZGVnN2v_sin", 2 },
|
|
|
|
{ "llvm.sin.f32", "_ZGVnN4v_sinf", 4 },
|
|
|
|
|
|
|
|
{ "sinh", "_ZGVnN2v_sinh", 2 },
|
|
|
|
{ "sinh", "_ZGVnN4v_sinhf", 4 },
|
|
|
|
{ "sinhf", "_ZGVnN4v_sinhf", 4 },
|
|
|
|
{ "llvm.sinh.f64", "_ZGVnN2v_sinh", 2 },
|
|
|
|
{ "llvm.sinh.f32", "_ZGVnN4v_sinhf", 4 },
|
|
|
|
|
|
|
|
{ "sqrt", "_ZGVnN2v_sqrt", 2 },
|
|
|
|
{ "sqrt", "_ZGVnN4v_sqrtf", 4 },
|
|
|
|
{ "sqrtf", "_ZGVnN4v_sqrtf", 4 },
|
|
|
|
{ "llvm.sqrt.f64", "_ZGVnN2v_sqrt", 2 },
|
|
|
|
{ "llvm.sqrt.f32", "_ZGVnN4v_sqrtf", 4 },
|
|
|
|
|
|
|
|
{ "tan", "_ZGVnN2v_tan", 2 },
|
|
|
|
{ "tan", "_ZGVnN4v_tanf", 4 },
|
|
|
|
{ "tanf", "_ZGVnN4v_tanf", 4 },
|
|
|
|
{ "llvm.tan.f64", "_ZGVnN2v_tan", 2 },
|
|
|
|
{ "llvm.tan.f32", "_ZGVnN4v_tanf", 4 },
|
|
|
|
|
|
|
|
{ "tanh", "_ZGVnN2v_tanh", 2 },
|
|
|
|
{ "tanh", "_ZGVnN4v_tanhf", 4 },
|
|
|
|
{ "tanhf", "_ZGVnN4v_tanhf", 4 },
|
|
|
|
{ "llvm.tanh.f64", "_ZGVnN2v_tanh", 2 },
|
|
|
|
{ "llvm.tanh.f32", "_ZGVnN4v_tanhf", 4 },
|
|
|
|
|
|
|
|
{ "tgamma", "_ZGVnN2v_tgamma", 2 },
|
|
|
|
{ "tgamma", "_ZGVnN4v_tgammaf", 4 },
|
|
|
|
{ "tgammaf", "_ZGVnN4v_tgammaf", 4 },
|
|
|
|
{ "llvm.tgamma.f64", "_ZGVnN2v_tgamma", 2 },
|
|
|
|
{ "llvm.tgamma.f32", "_ZGVnN4v_tgammaf", 4 },
|
|
|
|
};
|
|
|
|
addVectorizableFunctions(AArch64TwoAndFourLaneVecFuncs);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
2015-03-18 03:50:55 +08:00
|
|
|
case NoLibrary:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-03-18 03:22:30 +08:00
|
|
|
bool TargetLibraryInfoImpl::isFunctionVectorizable(StringRef funcName) const {
|
|
|
|
funcName = sanitizeFunctionName(funcName);
|
|
|
|
if (funcName.empty())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
std::vector<VecDesc>::const_iterator I = std::lower_bound(
|
|
|
|
VectorDescs.begin(), VectorDescs.end(), funcName,
|
|
|
|
compareWithScalarFnName);
|
|
|
|
return I != VectorDescs.end() && StringRef(I->ScalarFnName) == funcName;
|
|
|
|
}
|
|
|
|
|
|
|
|
StringRef TargetLibraryInfoImpl::getVectorizedFunction(StringRef F,
|
|
|
|
unsigned VF) const {
|
|
|
|
F = sanitizeFunctionName(F);
|
|
|
|
if (F.empty())
|
|
|
|
return F;
|
|
|
|
std::vector<VecDesc>::const_iterator I = std::lower_bound(
|
|
|
|
VectorDescs.begin(), VectorDescs.end(), F, compareWithScalarFnName);
|
|
|
|
while (I != VectorDescs.end() && StringRef(I->ScalarFnName) == F) {
|
|
|
|
if (I->VectorizationFactor == VF)
|
|
|
|
return I->VectorFnName;
|
|
|
|
++I;
|
|
|
|
}
|
|
|
|
return StringRef();
|
|
|
|
}
|
|
|
|
|
|
|
|
StringRef TargetLibraryInfoImpl::getScalarizedFunction(StringRef F,
|
|
|
|
unsigned &VF) const {
|
|
|
|
F = sanitizeFunctionName(F);
|
|
|
|
if (F.empty())
|
|
|
|
return F;
|
|
|
|
|
|
|
|
std::vector<VecDesc>::const_iterator I = std::lower_bound(
|
|
|
|
ScalarDescs.begin(), ScalarDescs.end(), F, compareWithVectorFnName);
|
|
|
|
if (I == VectorDescs.end() || StringRef(I->VectorFnName) != F)
|
|
|
|
return StringRef();
|
|
|
|
VF = I->VectorizationFactor;
|
|
|
|
return I->ScalarFnName;
|
|
|
|
}
|
|
|
|
|
2016-06-17 08:11:01 +08:00
|
|
|
TargetLibraryInfo TargetLibraryAnalysis::run(Module &M,
|
|
|
|
ModuleAnalysisManager &) {
|
[PM] Rework how the TargetLibraryInfo pass integrates with the new pass
manager to support the actual uses of it. =]
When I ported instcombine to the new pass manager I discover that it
didn't work because TLI wasn't available in the right places. This is
a somewhat surprising and/or subtle aspect of the new pass manager
design that came up before but I think is useful to be reminded of:
While the new pass manager *allows* a function pass to query a module
analysis, it requires that the module analysis is already run and cached
prior to the function pass manager starting up, possibly with
a 'require<foo>' style utility in the pass pipeline. This is an
intentional hurdle because using a module analysis from a function pass
*requires* that the module analysis is run prior to entering the
function pass manager. Otherwise the other functions in the module could
be in who-knows-what state, etc.
A somewhat surprising consequence of this design decision (at least to
me) is that you have to design a function pass that leverages
a module analysis to do so as an optional feature. Even if that means
your function pass does no work in the absence of the module analysis,
you have to handle that possibility and remain conservatively correct.
This is a natural consequence of things being able to invalidate the
module analysis and us being unable to re-run it. And it's a generally
good thing because it lets us reorder passes arbitrarily without
breaking correctness, etc.
This ends up causing problems in one case. What if we have a module
analysis that is *definitionally* impossible to invalidate. In the
places this might come up, the analysis is usually also definitionally
trivial to run even while other transformation passes run on the module,
regardless of the state of anything. And so, it follows that it is
natural to have a hard requirement on such analyses from a function
pass.
It turns out, that TargetLibraryInfo is just such an analysis, and
InstCombine has a hard requirement on it.
The approach I've taken here is to produce an analysis that models this
flexibility by making it both a module and a function analysis. This
exposes the fact that it is in fact safe to compute at any point. We can
even make it a valid CGSCC analysis at some point if that is useful.
However, we don't want to have a copy of the actual target library info
state for each function! This state is specific to the triple. The
somewhat direct and blunt approach here is to turn TLI into a pimpl,
with the state and mutators in the implementation class and the query
routines primarily in the wrapper. Then the analysis can lazily
construct and cache the implementations, keyed on the triple, and
on-demand produce wrappers of them for each function.
One minor annoyance is that we will end up with a wrapper for each
function in the module. While this is a bit wasteful (one pointer per
function) it seems tolerable. And it has the advantage of ensuring that
we pay the absolute minimum synchronization cost to access this
information should we end up with a nice parallel function pass manager
in the future. We could look into trying to mark when analysis results
are especially cheap to recompute and more eagerly GC-ing the cached
results, or we could look at supporting a variant of analyses whose
results are specifically *not* cached and expected to just be used and
discarded by the consumer. Either way, these seem like incremental
enhancements that should happen when we start profiling the memory and
CPU usage of the new pass manager and not before.
The other minor annoyance is that if we end up using the TLI in both
a module pass and a function pass, those will be produced by two
separate analyses, and thus will point to separate copies of the
implementation state. While a minor issue, I dislike this and would like
to find a way to cleanly allow a single analysis instance to be used
across multiple IR unit managers. But I don't have a good solution to
this today, and I don't want to hold up all of the work waiting to come
up with one. This too seems like a reasonable thing to incrementally
improve later.
llvm-svn: 226981
2015-01-24 10:06:09 +08:00
|
|
|
if (PresetInfoImpl)
|
|
|
|
return TargetLibraryInfo(*PresetInfoImpl);
|
|
|
|
|
|
|
|
return TargetLibraryInfo(lookupInfoImpl(Triple(M.getTargetTriple())));
|
|
|
|
}
|
|
|
|
|
2016-06-17 08:11:01 +08:00
|
|
|
TargetLibraryInfo TargetLibraryAnalysis::run(Function &F,
|
|
|
|
FunctionAnalysisManager &) {
|
[PM] Rework how the TargetLibraryInfo pass integrates with the new pass
manager to support the actual uses of it. =]
When I ported instcombine to the new pass manager I discover that it
didn't work because TLI wasn't available in the right places. This is
a somewhat surprising and/or subtle aspect of the new pass manager
design that came up before but I think is useful to be reminded of:
While the new pass manager *allows* a function pass to query a module
analysis, it requires that the module analysis is already run and cached
prior to the function pass manager starting up, possibly with
a 'require<foo>' style utility in the pass pipeline. This is an
intentional hurdle because using a module analysis from a function pass
*requires* that the module analysis is run prior to entering the
function pass manager. Otherwise the other functions in the module could
be in who-knows-what state, etc.
A somewhat surprising consequence of this design decision (at least to
me) is that you have to design a function pass that leverages
a module analysis to do so as an optional feature. Even if that means
your function pass does no work in the absence of the module analysis,
you have to handle that possibility and remain conservatively correct.
This is a natural consequence of things being able to invalidate the
module analysis and us being unable to re-run it. And it's a generally
good thing because it lets us reorder passes arbitrarily without
breaking correctness, etc.
This ends up causing problems in one case. What if we have a module
analysis that is *definitionally* impossible to invalidate. In the
places this might come up, the analysis is usually also definitionally
trivial to run even while other transformation passes run on the module,
regardless of the state of anything. And so, it follows that it is
natural to have a hard requirement on such analyses from a function
pass.
It turns out, that TargetLibraryInfo is just such an analysis, and
InstCombine has a hard requirement on it.
The approach I've taken here is to produce an analysis that models this
flexibility by making it both a module and a function analysis. This
exposes the fact that it is in fact safe to compute at any point. We can
even make it a valid CGSCC analysis at some point if that is useful.
However, we don't want to have a copy of the actual target library info
state for each function! This state is specific to the triple. The
somewhat direct and blunt approach here is to turn TLI into a pimpl,
with the state and mutators in the implementation class and the query
routines primarily in the wrapper. Then the analysis can lazily
construct and cache the implementations, keyed on the triple, and
on-demand produce wrappers of them for each function.
One minor annoyance is that we will end up with a wrapper for each
function in the module. While this is a bit wasteful (one pointer per
function) it seems tolerable. And it has the advantage of ensuring that
we pay the absolute minimum synchronization cost to access this
information should we end up with a nice parallel function pass manager
in the future. We could look into trying to mark when analysis results
are especially cheap to recompute and more eagerly GC-ing the cached
results, or we could look at supporting a variant of analyses whose
results are specifically *not* cached and expected to just be used and
discarded by the consumer. Either way, these seem like incremental
enhancements that should happen when we start profiling the memory and
CPU usage of the new pass manager and not before.
The other minor annoyance is that if we end up using the TLI in both
a module pass and a function pass, those will be produced by two
separate analyses, and thus will point to separate copies of the
implementation state. While a minor issue, I dislike this and would like
to find a way to cleanly allow a single analysis instance to be used
across multiple IR unit managers. But I don't have a good solution to
this today, and I don't want to hold up all of the work waiting to come
up with one. This too seems like a reasonable thing to incrementally
improve later.
llvm-svn: 226981
2015-01-24 10:06:09 +08:00
|
|
|
if (PresetInfoImpl)
|
|
|
|
return TargetLibraryInfo(*PresetInfoImpl);
|
|
|
|
|
|
|
|
return TargetLibraryInfo(
|
|
|
|
lookupInfoImpl(Triple(F.getParent()->getTargetTriple())));
|
|
|
|
}
|
|
|
|
|
2016-06-09 03:09:22 +08:00
|
|
|
TargetLibraryInfoImpl &TargetLibraryAnalysis::lookupInfoImpl(const Triple &T) {
|
[PM] Rework how the TargetLibraryInfo pass integrates with the new pass
manager to support the actual uses of it. =]
When I ported instcombine to the new pass manager I discover that it
didn't work because TLI wasn't available in the right places. This is
a somewhat surprising and/or subtle aspect of the new pass manager
design that came up before but I think is useful to be reminded of:
While the new pass manager *allows* a function pass to query a module
analysis, it requires that the module analysis is already run and cached
prior to the function pass manager starting up, possibly with
a 'require<foo>' style utility in the pass pipeline. This is an
intentional hurdle because using a module analysis from a function pass
*requires* that the module analysis is run prior to entering the
function pass manager. Otherwise the other functions in the module could
be in who-knows-what state, etc.
A somewhat surprising consequence of this design decision (at least to
me) is that you have to design a function pass that leverages
a module analysis to do so as an optional feature. Even if that means
your function pass does no work in the absence of the module analysis,
you have to handle that possibility and remain conservatively correct.
This is a natural consequence of things being able to invalidate the
module analysis and us being unable to re-run it. And it's a generally
good thing because it lets us reorder passes arbitrarily without
breaking correctness, etc.
This ends up causing problems in one case. What if we have a module
analysis that is *definitionally* impossible to invalidate. In the
places this might come up, the analysis is usually also definitionally
trivial to run even while other transformation passes run on the module,
regardless of the state of anything. And so, it follows that it is
natural to have a hard requirement on such analyses from a function
pass.
It turns out, that TargetLibraryInfo is just such an analysis, and
InstCombine has a hard requirement on it.
The approach I've taken here is to produce an analysis that models this
flexibility by making it both a module and a function analysis. This
exposes the fact that it is in fact safe to compute at any point. We can
even make it a valid CGSCC analysis at some point if that is useful.
However, we don't want to have a copy of the actual target library info
state for each function! This state is specific to the triple. The
somewhat direct and blunt approach here is to turn TLI into a pimpl,
with the state and mutators in the implementation class and the query
routines primarily in the wrapper. Then the analysis can lazily
construct and cache the implementations, keyed on the triple, and
on-demand produce wrappers of them for each function.
One minor annoyance is that we will end up with a wrapper for each
function in the module. While this is a bit wasteful (one pointer per
function) it seems tolerable. And it has the advantage of ensuring that
we pay the absolute minimum synchronization cost to access this
information should we end up with a nice parallel function pass manager
in the future. We could look into trying to mark when analysis results
are especially cheap to recompute and more eagerly GC-ing the cached
results, or we could look at supporting a variant of analyses whose
results are specifically *not* cached and expected to just be used and
discarded by the consumer. Either way, these seem like incremental
enhancements that should happen when we start profiling the memory and
CPU usage of the new pass manager and not before.
The other minor annoyance is that if we end up using the TLI in both
a module pass and a function pass, those will be produced by two
separate analyses, and thus will point to separate copies of the
implementation state. While a minor issue, I dislike this and would like
to find a way to cleanly allow a single analysis instance to be used
across multiple IR unit managers. But I don't have a good solution to
this today, and I don't want to hold up all of the work waiting to come
up with one. This too seems like a reasonable thing to incrementally
improve later.
llvm-svn: 226981
2015-01-24 10:06:09 +08:00
|
|
|
std::unique_ptr<TargetLibraryInfoImpl> &Impl =
|
|
|
|
Impls[T.normalize()];
|
|
|
|
if (!Impl)
|
|
|
|
Impl.reset(new TargetLibraryInfoImpl(T));
|
|
|
|
|
|
|
|
return *Impl;
|
|
|
|
}
|
|
|
|
|
2017-05-20 06:37:09 +08:00
|
|
|
unsigned TargetLibraryInfoImpl::getWCharSize(const Module &M) const {
|
|
|
|
if (auto *ShortWChar = cast_or_null<ConstantAsMetadata>(
|
|
|
|
M.getModuleFlag("wchar_size")))
|
|
|
|
return cast<ConstantInt>(ShortWChar->getValue())->getZExtValue();
|
2017-09-26 10:36:57 +08:00
|
|
|
return 0;
|
2017-05-20 06:37:09 +08:00
|
|
|
}
|
[PM] Rework how the TargetLibraryInfo pass integrates with the new pass
manager to support the actual uses of it. =]
When I ported instcombine to the new pass manager I discover that it
didn't work because TLI wasn't available in the right places. This is
a somewhat surprising and/or subtle aspect of the new pass manager
design that came up before but I think is useful to be reminded of:
While the new pass manager *allows* a function pass to query a module
analysis, it requires that the module analysis is already run and cached
prior to the function pass manager starting up, possibly with
a 'require<foo>' style utility in the pass pipeline. This is an
intentional hurdle because using a module analysis from a function pass
*requires* that the module analysis is run prior to entering the
function pass manager. Otherwise the other functions in the module could
be in who-knows-what state, etc.
A somewhat surprising consequence of this design decision (at least to
me) is that you have to design a function pass that leverages
a module analysis to do so as an optional feature. Even if that means
your function pass does no work in the absence of the module analysis,
you have to handle that possibility and remain conservatively correct.
This is a natural consequence of things being able to invalidate the
module analysis and us being unable to re-run it. And it's a generally
good thing because it lets us reorder passes arbitrarily without
breaking correctness, etc.
This ends up causing problems in one case. What if we have a module
analysis that is *definitionally* impossible to invalidate. In the
places this might come up, the analysis is usually also definitionally
trivial to run even while other transformation passes run on the module,
regardless of the state of anything. And so, it follows that it is
natural to have a hard requirement on such analyses from a function
pass.
It turns out, that TargetLibraryInfo is just such an analysis, and
InstCombine has a hard requirement on it.
The approach I've taken here is to produce an analysis that models this
flexibility by making it both a module and a function analysis. This
exposes the fact that it is in fact safe to compute at any point. We can
even make it a valid CGSCC analysis at some point if that is useful.
However, we don't want to have a copy of the actual target library info
state for each function! This state is specific to the triple. The
somewhat direct and blunt approach here is to turn TLI into a pimpl,
with the state and mutators in the implementation class and the query
routines primarily in the wrapper. Then the analysis can lazily
construct and cache the implementations, keyed on the triple, and
on-demand produce wrappers of them for each function.
One minor annoyance is that we will end up with a wrapper for each
function in the module. While this is a bit wasteful (one pointer per
function) it seems tolerable. And it has the advantage of ensuring that
we pay the absolute minimum synchronization cost to access this
information should we end up with a nice parallel function pass manager
in the future. We could look into trying to mark when analysis results
are especially cheap to recompute and more eagerly GC-ing the cached
results, or we could look at supporting a variant of analyses whose
results are specifically *not* cached and expected to just be used and
discarded by the consumer. Either way, these seem like incremental
enhancements that should happen when we start profiling the memory and
CPU usage of the new pass manager and not before.
The other minor annoyance is that if we end up using the TLI in both
a module pass and a function pass, those will be produced by two
separate analyses, and thus will point to separate copies of the
implementation state. While a minor issue, I dislike this and would like
to find a way to cleanly allow a single analysis instance to be used
across multiple IR unit managers. But I don't have a good solution to
this today, and I don't want to hold up all of the work waiting to come
up with one. This too seems like a reasonable thing to incrementally
improve later.
llvm-svn: 226981
2015-01-24 10:06:09 +08:00
|
|
|
|
2015-01-15 18:41:28 +08:00
|
|
|
TargetLibraryInfoWrapperPass::TargetLibraryInfoWrapperPass()
|
[PM] Rework how the TargetLibraryInfo pass integrates with the new pass
manager to support the actual uses of it. =]
When I ported instcombine to the new pass manager I discover that it
didn't work because TLI wasn't available in the right places. This is
a somewhat surprising and/or subtle aspect of the new pass manager
design that came up before but I think is useful to be reminded of:
While the new pass manager *allows* a function pass to query a module
analysis, it requires that the module analysis is already run and cached
prior to the function pass manager starting up, possibly with
a 'require<foo>' style utility in the pass pipeline. This is an
intentional hurdle because using a module analysis from a function pass
*requires* that the module analysis is run prior to entering the
function pass manager. Otherwise the other functions in the module could
be in who-knows-what state, etc.
A somewhat surprising consequence of this design decision (at least to
me) is that you have to design a function pass that leverages
a module analysis to do so as an optional feature. Even if that means
your function pass does no work in the absence of the module analysis,
you have to handle that possibility and remain conservatively correct.
This is a natural consequence of things being able to invalidate the
module analysis and us being unable to re-run it. And it's a generally
good thing because it lets us reorder passes arbitrarily without
breaking correctness, etc.
This ends up causing problems in one case. What if we have a module
analysis that is *definitionally* impossible to invalidate. In the
places this might come up, the analysis is usually also definitionally
trivial to run even while other transformation passes run on the module,
regardless of the state of anything. And so, it follows that it is
natural to have a hard requirement on such analyses from a function
pass.
It turns out, that TargetLibraryInfo is just such an analysis, and
InstCombine has a hard requirement on it.
The approach I've taken here is to produce an analysis that models this
flexibility by making it both a module and a function analysis. This
exposes the fact that it is in fact safe to compute at any point. We can
even make it a valid CGSCC analysis at some point if that is useful.
However, we don't want to have a copy of the actual target library info
state for each function! This state is specific to the triple. The
somewhat direct and blunt approach here is to turn TLI into a pimpl,
with the state and mutators in the implementation class and the query
routines primarily in the wrapper. Then the analysis can lazily
construct and cache the implementations, keyed on the triple, and
on-demand produce wrappers of them for each function.
One minor annoyance is that we will end up with a wrapper for each
function in the module. While this is a bit wasteful (one pointer per
function) it seems tolerable. And it has the advantage of ensuring that
we pay the absolute minimum synchronization cost to access this
information should we end up with a nice parallel function pass manager
in the future. We could look into trying to mark when analysis results
are especially cheap to recompute and more eagerly GC-ing the cached
results, or we could look at supporting a variant of analyses whose
results are specifically *not* cached and expected to just be used and
discarded by the consumer. Either way, these seem like incremental
enhancements that should happen when we start profiling the memory and
CPU usage of the new pass manager and not before.
The other minor annoyance is that if we end up using the TLI in both
a module pass and a function pass, those will be produced by two
separate analyses, and thus will point to separate copies of the
implementation state. While a minor issue, I dislike this and would like
to find a way to cleanly allow a single analysis instance to be used
across multiple IR unit managers. But I don't have a good solution to
this today, and I don't want to hold up all of the work waiting to come
up with one. This too seems like a reasonable thing to incrementally
improve later.
llvm-svn: 226981
2015-01-24 10:06:09 +08:00
|
|
|
: ImmutablePass(ID), TLIImpl(), TLI(TLIImpl) {
|
2015-01-15 18:41:28 +08:00
|
|
|
initializeTargetLibraryInfoWrapperPassPass(*PassRegistry::getPassRegistry());
|
|
|
|
}
|
|
|
|
|
|
|
|
TargetLibraryInfoWrapperPass::TargetLibraryInfoWrapperPass(const Triple &T)
|
[PM] Rework how the TargetLibraryInfo pass integrates with the new pass
manager to support the actual uses of it. =]
When I ported instcombine to the new pass manager I discover that it
didn't work because TLI wasn't available in the right places. This is
a somewhat surprising and/or subtle aspect of the new pass manager
design that came up before but I think is useful to be reminded of:
While the new pass manager *allows* a function pass to query a module
analysis, it requires that the module analysis is already run and cached
prior to the function pass manager starting up, possibly with
a 'require<foo>' style utility in the pass pipeline. This is an
intentional hurdle because using a module analysis from a function pass
*requires* that the module analysis is run prior to entering the
function pass manager. Otherwise the other functions in the module could
be in who-knows-what state, etc.
A somewhat surprising consequence of this design decision (at least to
me) is that you have to design a function pass that leverages
a module analysis to do so as an optional feature. Even if that means
your function pass does no work in the absence of the module analysis,
you have to handle that possibility and remain conservatively correct.
This is a natural consequence of things being able to invalidate the
module analysis and us being unable to re-run it. And it's a generally
good thing because it lets us reorder passes arbitrarily without
breaking correctness, etc.
This ends up causing problems in one case. What if we have a module
analysis that is *definitionally* impossible to invalidate. In the
places this might come up, the analysis is usually also definitionally
trivial to run even while other transformation passes run on the module,
regardless of the state of anything. And so, it follows that it is
natural to have a hard requirement on such analyses from a function
pass.
It turns out, that TargetLibraryInfo is just such an analysis, and
InstCombine has a hard requirement on it.
The approach I've taken here is to produce an analysis that models this
flexibility by making it both a module and a function analysis. This
exposes the fact that it is in fact safe to compute at any point. We can
even make it a valid CGSCC analysis at some point if that is useful.
However, we don't want to have a copy of the actual target library info
state for each function! This state is specific to the triple. The
somewhat direct and blunt approach here is to turn TLI into a pimpl,
with the state and mutators in the implementation class and the query
routines primarily in the wrapper. Then the analysis can lazily
construct and cache the implementations, keyed on the triple, and
on-demand produce wrappers of them for each function.
One minor annoyance is that we will end up with a wrapper for each
function in the module. While this is a bit wasteful (one pointer per
function) it seems tolerable. And it has the advantage of ensuring that
we pay the absolute minimum synchronization cost to access this
information should we end up with a nice parallel function pass manager
in the future. We could look into trying to mark when analysis results
are especially cheap to recompute and more eagerly GC-ing the cached
results, or we could look at supporting a variant of analyses whose
results are specifically *not* cached and expected to just be used and
discarded by the consumer. Either way, these seem like incremental
enhancements that should happen when we start profiling the memory and
CPU usage of the new pass manager and not before.
The other minor annoyance is that if we end up using the TLI in both
a module pass and a function pass, those will be produced by two
separate analyses, and thus will point to separate copies of the
implementation state. While a minor issue, I dislike this and would like
to find a way to cleanly allow a single analysis instance to be used
across multiple IR unit managers. But I don't have a good solution to
this today, and I don't want to hold up all of the work waiting to come
up with one. This too seems like a reasonable thing to incrementally
improve later.
llvm-svn: 226981
2015-01-24 10:06:09 +08:00
|
|
|
: ImmutablePass(ID), TLIImpl(T), TLI(TLIImpl) {
|
2015-01-15 18:41:28 +08:00
|
|
|
initializeTargetLibraryInfoWrapperPassPass(*PassRegistry::getPassRegistry());
|
|
|
|
}
|
|
|
|
|
|
|
|
TargetLibraryInfoWrapperPass::TargetLibraryInfoWrapperPass(
|
[PM] Rework how the TargetLibraryInfo pass integrates with the new pass
manager to support the actual uses of it. =]
When I ported instcombine to the new pass manager I discover that it
didn't work because TLI wasn't available in the right places. This is
a somewhat surprising and/or subtle aspect of the new pass manager
design that came up before but I think is useful to be reminded of:
While the new pass manager *allows* a function pass to query a module
analysis, it requires that the module analysis is already run and cached
prior to the function pass manager starting up, possibly with
a 'require<foo>' style utility in the pass pipeline. This is an
intentional hurdle because using a module analysis from a function pass
*requires* that the module analysis is run prior to entering the
function pass manager. Otherwise the other functions in the module could
be in who-knows-what state, etc.
A somewhat surprising consequence of this design decision (at least to
me) is that you have to design a function pass that leverages
a module analysis to do so as an optional feature. Even if that means
your function pass does no work in the absence of the module analysis,
you have to handle that possibility and remain conservatively correct.
This is a natural consequence of things being able to invalidate the
module analysis and us being unable to re-run it. And it's a generally
good thing because it lets us reorder passes arbitrarily without
breaking correctness, etc.
This ends up causing problems in one case. What if we have a module
analysis that is *definitionally* impossible to invalidate. In the
places this might come up, the analysis is usually also definitionally
trivial to run even while other transformation passes run on the module,
regardless of the state of anything. And so, it follows that it is
natural to have a hard requirement on such analyses from a function
pass.
It turns out, that TargetLibraryInfo is just such an analysis, and
InstCombine has a hard requirement on it.
The approach I've taken here is to produce an analysis that models this
flexibility by making it both a module and a function analysis. This
exposes the fact that it is in fact safe to compute at any point. We can
even make it a valid CGSCC analysis at some point if that is useful.
However, we don't want to have a copy of the actual target library info
state for each function! This state is specific to the triple. The
somewhat direct and blunt approach here is to turn TLI into a pimpl,
with the state and mutators in the implementation class and the query
routines primarily in the wrapper. Then the analysis can lazily
construct and cache the implementations, keyed on the triple, and
on-demand produce wrappers of them for each function.
One minor annoyance is that we will end up with a wrapper for each
function in the module. While this is a bit wasteful (one pointer per
function) it seems tolerable. And it has the advantage of ensuring that
we pay the absolute minimum synchronization cost to access this
information should we end up with a nice parallel function pass manager
in the future. We could look into trying to mark when analysis results
are especially cheap to recompute and more eagerly GC-ing the cached
results, or we could look at supporting a variant of analyses whose
results are specifically *not* cached and expected to just be used and
discarded by the consumer. Either way, these seem like incremental
enhancements that should happen when we start profiling the memory and
CPU usage of the new pass manager and not before.
The other minor annoyance is that if we end up using the TLI in both
a module pass and a function pass, those will be produced by two
separate analyses, and thus will point to separate copies of the
implementation state. While a minor issue, I dislike this and would like
to find a way to cleanly allow a single analysis instance to be used
across multiple IR unit managers. But I don't have a good solution to
this today, and I don't want to hold up all of the work waiting to come
up with one. This too seems like a reasonable thing to incrementally
improve later.
llvm-svn: 226981
2015-01-24 10:06:09 +08:00
|
|
|
const TargetLibraryInfoImpl &TLIImpl)
|
|
|
|
: ImmutablePass(ID), TLIImpl(TLIImpl), TLI(this->TLIImpl) {
|
2015-01-15 18:41:28 +08:00
|
|
|
initializeTargetLibraryInfoWrapperPassPass(*PassRegistry::getPassRegistry());
|
|
|
|
}
|
|
|
|
|
2016-11-24 01:53:26 +08:00
|
|
|
AnalysisKey TargetLibraryAnalysis::Key;
|
2016-02-29 01:17:00 +08:00
|
|
|
|
2015-01-15 18:41:28 +08:00
|
|
|
// Register the basic pass.
|
|
|
|
INITIALIZE_PASS(TargetLibraryInfoWrapperPass, "targetlibinfo",
|
|
|
|
"Target Library Information", false, true)
|
|
|
|
char TargetLibraryInfoWrapperPass::ID = 0;
|
|
|
|
|
|
|
|
void TargetLibraryInfoWrapperPass::anchor() {}
|