RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-24 05:23:45 +02:00
Code Issues Projects Releases Wiki Activity
cef3c53d65
llvm-mirror/lib/Analysis/TargetLibraryInfo.cpp

1276 lines
45 KiB
C++
Raw Normal View History

introduce a new TargetLibraryInfo pass, which transformations can use to query about available library functions. For now this just has memset_pattern16, which exists on darwin, but it can be extended for a bunch of other things in the future. llvm-svn: 125965
2011-02-18 22:50:34 +01: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.
//
//===----------------------------------------------------------------------===//
[PM] Move TargetLibraryInfo into the Analysis library. While the term "Target" is in the name, it doesn't really have to do with the LLVM Target library -- this isn't an abstraction which LLVM targets generally need to implement or extend. It has much more to do with modeling the various runtime libraries on different OSes and with different runtime environments. The "target" in this sense is the more general sense of a target of cross compilation. This is in preparation for porting this analysis to the new pass manager. No functionality changed, and updates inbound for Clang and Polly. llvm-svn: 226078
2015-01-15 03:16:27 +01:00
#include "llvm/Analysis/TargetLibraryInfo.h"
introduce a new TargetLibraryInfo pass, which transformations can use to query about available library functions. For now this just has memset_pattern16, which exists on darwin, but it can be extended for a bunch of other things in the future. llvm-svn: 125965
2011-02-18 22:50:34 +01:00
#include "llvm/ADT/Triple.h"
TLI: Add addVectorizableFunctionsFromVecLib. Also, add several entries to vectorizable functions table, and corresponding tests. The table isn't complete, it'll be populated later. Review: http://reviews.llvm.org/D8131 llvm-svn: 232531
2015-03-17 20:50:55 +01:00
#include "llvm/Support/CommandLine.h"
introduce a new TargetLibraryInfo pass, which transformations can use to query about available library functions. For now this just has memset_pattern16, which exists on darwin, but it can be extended for a bunch of other things in the future. llvm-svn: 125965
2011-02-18 22:50:34 +01:00
using namespace llvm;
TLI: Add addVectorizableFunctionsFromVecLib. Also, add several entries to vectorizable functions table, and corresponding tests. The table isn't complete, it'll be populated later. Review: http://reviews.llvm.org/D8131 llvm-svn: 232531
2015-03-17 20:50:55 +01: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"),
Initial support for vectorization using svml (short vector math library). Differential Revision: https://reviews.llvm.org/D19544 llvm-svn: 277166
2016-07-29 18:42:44 +02:00
clEnumValN(TargetLibraryInfoImpl::SVML, "SVML",
Turn cl::values() (for enum) from a vararg function to using C++ variadic template The core of the change is supposed to be NFC, however it also fixes what I believe was an undefined behavior when calling: va_start(ValueArgs, Desc); with Desc being a StringRef. Differential Revision: https://reviews.llvm.org/D25342 llvm-svn: 283671
2016-10-08 21:41:06 +02:00
"Intel SVML library")));
TLI: Add addVectorizableFunctionsFromVecLib. Also, add several entries to vectorizable functions table, and corresponding tests. The table isn't complete, it'll be populated later. Review: http://reviews.llvm.org/D8131 llvm-svn: 232531
2015-03-17 20:50:55 +01:00
Use StringRef in TLI instead of raw pointer (NFC) llvm-svn: 283005
2016-10-01 05:10:48 +02:00
StringRef const TargetLibraryInfoImpl::StandardNames[LibFunc::NumLibFuncs] = {
Move TargetLibraryInfo data from two files into one common .def file. Summary: This makes it more obvious that the enum definition and the "StandardName" array is in sync. Mechanically refactored w/ a python script. Test Plan: still compiles Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D7845 llvm-svn: 231172
2015-03-04 00:41:58 +01:00
#define TLI_DEFINE_STRING
#include "llvm/Analysis/TargetLibraryInfo.def"
Make static variables const if possible. Makes them go into a read-only section. Or fold them into a initializer list which has the same effect. NFC. llvm-svn: 231598
2015-03-08 17:07:39 +01:00
};
Add support for custom names for library functions in TargetLibraryInfo. Add a custom name for fwrite and fputs on x86-32 OSX. Make SimplifyLibCalls honor the custom names for fwrite and fputs. Fixes <rdar://problem/9815881>. llvm-svn: 144876
2011-11-17 02:27:36 +01:00
Convert calls to __sinpi and __cospi into __sincospi_stret This adds an SimplifyLibCalls case which converts the special __sinpi and __cospi (float & double variants) into a __sincospi_stret where appropriate to remove duplicated work. Patch by Tim Northover llvm-svn: 193943
2013-11-03 07:48:38 +01:00
static bool hasSinCosPiStret(const Triple &T) {
// Only Darwin variants have _stret versions of combined trig functions.
Use triple's isiOS() and isOSDarwin() methods. These methods are already used in lots of places. This makes things more consistent. NFC. llvm-svn: 219386
2014-10-09 07:43:30 +02:00
if (!T.isOSDarwin())
Convert calls to __sinpi and __cospi into __sincospi_stret This adds an SimplifyLibCalls case which converts the special __sinpi and __cospi (float & double variants) into a __sincospi_stret where appropriate to remove duplicated work. Patch by Tim Northover llvm-svn: 193943
2013-11-03 07:48:38 +01: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;
Use triple's isiOS() and isOSDarwin() methods. These methods are already used in lots of places. This makes things more consistent. NFC. llvm-svn: 219386
2014-10-09 07:43:30 +02:00
if (T.isiOS() && T.isOSVersionLT(7, 0))
Convert calls to __sinpi and __cospi into __sincospi_stret This adds an SimplifyLibCalls case which converts the special __sinpi and __cospi (float & double variants) into a __sincospi_stret where appropriate to remove duplicated work. Patch by Tim Northover llvm-svn: 193943
2013-11-03 07:48:38 +01:00
return false;
return true;
}
introduce a new TargetLibraryInfo pass, which transformations can use to query about available library functions. For now this just has memset_pattern16, which exists on darwin, but it can be extended for a bunch of other things in the future. llvm-svn: 125965
2011-02-18 22:50:34 +01:00
/// initialize - 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 03:06:09 +01:00
static void initialize(TargetLibraryInfoImpl &TLI, const Triple &T,
Use StringRef in TLI instead of raw pointer (NFC) llvm-svn: 283005
2016-10-01 05:10:48 +02:00
ArrayRef<StringRef> StandardNames) {
Add new getLibFunc method to TargetLibraryInfo. This just provides a way to look up a LibFunc::Func enum value for a function name. Alphabetize the enums and function names so we can use a binary search. llvm-svn: 161231
2012-08-03 06:06:22 +02:00
// Verify that the StandardNames array is in alphabetical order.
Use std::is_sorted and std::none_of instead of manual loops. NFC llvm-svn: 256719
2016-01-03 20:43:40 +01:00
assert(std::is_sorted(StandardNames.begin(), StandardNames.end(),
Use StringRef in TLI instead of raw pointer (NFC) llvm-svn: 283005
2016-10-01 05:10:48 +02:00
[](StringRef LHS, StringRef RHS) {
return LHS < RHS;
Use std::is_sorted and std::none_of instead of manual loops. NFC llvm-svn: 256719
2016-01-03 20:43:40 +01:00
}) &&
"TargetLibraryInfoImpl function names must be sorted");
TargetLibraryInfo: Disable memcpy and memset on R600 There are no implementations of these for R600. llvm-svn: 205455
2014-04-02 21:53:29 +02:00
[TLI] Fix breakage introduced by D21739. The initialize function has an early return for AMDGPU targets. If taken, the ShouldExtI32* initialization code will not be executed, resulting in invalid values in the corresponding fields. Fix this by moving the code to the top of the function. llvm-svn: 287570
2016-11-21 21:20:39 +01: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.
if (T.getArch() == Triple::mips || T.getArch() == Triple::mipsel ||
T.getArch() == Triple::mips64 || T.getArch() == Triple::mips64el) {
ShouldSignExtI32Param = true;
}
TLI.setShouldExtI32Param(ShouldExtI32Param);
TLI.setShouldExtI32Return(ShouldExtI32Return);
TLI.setShouldSignExtI32Param(ShouldSignExtI32Param);
AMDGPU: mark ldexp LibCalls as unavailable Summary: The LibCallSimplifier will turn llvm.exp2.* intrinsics into ldexp* libcalls which do not make sense with the AMDGPU backend. In the long run, we'll want an llvm.ldexp.* intrinsic to properly make use of this optimization, but this works around the problem for now. See also: http://reviews.llvm.org/D14327 (suggested llvm.ldexp.* implementation) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92709 Reviewers: arsenm, tstellarAMD Differential Revision: http://reviews.llvm.org/D14990 llvm-svn: 255658
2015-12-15 18:24:15 +01:00
if (T.getArch() == Triple::r600 ||
T.getArch() == Triple::amdgcn) {
TLI.setUnavailable(LibFunc::ldexp);
TLI.setUnavailable(LibFunc::ldexpf);
TLI.setUnavailable(LibFunc::ldexpl);
AMDGPU: mark {exp,log}10{,f,l} library functions as unavailable Summary: The SimplifyLibCalls part of InstCombine generates calls to those otherwise. I wonder if at some point we shouldn't just call disableAllFunctions() and then enable functions on a whitelist basis... Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96495 Reviewers: arsenm, tstellarAMD Subscribers: llvm-commits, kzhuravl Differential Revision: http://reviews.llvm.org/D21282 llvm-svn: 272664
2016-06-14 15:14:53 +02:00
TLI.setUnavailable(LibFunc::exp10);
TLI.setUnavailable(LibFunc::exp10f);
TLI.setUnavailable(LibFunc::exp10l);
TLI.setUnavailable(LibFunc::log10);
TLI.setUnavailable(LibFunc::log10f);
TLI.setUnavailable(LibFunc::log10l);
AMDGPU: mark ldexp LibCalls as unavailable Summary: The LibCallSimplifier will turn llvm.exp2.* intrinsics into ldexp* libcalls which do not make sense with the AMDGPU backend. In the long run, we'll want an llvm.ldexp.* intrinsic to properly make use of this optimization, but this works around the problem for now. See also: http://reviews.llvm.org/D14327 (suggested llvm.ldexp.* implementation) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92709 Reviewers: arsenm, tstellarAMD Differential Revision: http://reviews.llvm.org/D14990 llvm-svn: 255658
2015-12-15 18:24:15 +01:00
}
R600/SI: Add check for amdgcn triple forgotten in r225276. llvm-svn: 225331
2015-01-07 02:17:37 +01:00
// There are no library implementations of mempcy and memset for AMD gpus and
TargetLibraryInfo: Disable memcpy and memset on R600 There are no implementations of these for R600. llvm-svn: 205455
2014-04-02 21:53:29 +02:00
// these can be difficult to lower in the backend.
R600/SI: Add check for amdgcn triple forgotten in r225276. llvm-svn: 225331
2015-01-07 02:17:37 +01:00
if (T.getArch() == Triple::r600 ||
[WebAssembly] Re-enable loop idiom recognition for memcpy et al. llvm-svn: 258125
2016-01-19 15:49:23 +01:00
T.getArch() == Triple::amdgcn) {
TargetLibraryInfo: Disable memcpy and memset on R600 There are no implementations of these for R600. llvm-svn: 205455
2014-04-02 21:53:29 +02:00
TLI.setUnavailable(LibFunc::memcpy);
TLI.setUnavailable(LibFunc::memset);
TLI.setUnavailable(LibFunc::memset_pattern16);
return;
}
"Mac OS/X" -> "Mac OS X" spelling fixes for llvm. Patch from Sean McBride <sean@rogue-research.com>! llvm-svn: 203258
2014-03-07 19:08:54 +01:00
// memset_pattern16 is only available on iOS 3.0 and Mac OS X 10.5 and later.
ARM: teach backend about WatchOS and TvOS libcalls. The most substantial changes are again for watchOS: libcalls are hard-float if needed and sincos has a different calling convention. llvm-svn: 251571
2015-10-28 23:51:16 +01:00
// All versions of watchOS support it.
ADT/Triple: Renambe isOSX... methods to isMacOSX for consistency with the OS triple component. llvm-svn: 129838
2011-04-20 02:14:25 +02:00
if (T.isMacOSX()) {
if (T.isMacOSXVersionLT(10, 5))
Target: Eliminate a use of getDarwinMajorNumber(). llvm-svn: 129803
2011-04-19 22:44:08 +02:00
TLI.setUnavailable(LibFunc::memset_pattern16);
Clean up some usage of Triple. The base class has methods for determining if the target is iOS and Linux. llvm-svn: 189604
2013-08-29 22:23:14 +02:00
} else if (T.isiOS()) {
Target: Eliminate a use of getDarwinMajorNumber(). llvm-svn: 129803
2011-04-19 22:44:08 +02:00
if (T.isOSVersionLT(3, 0))
TLI.setUnavailable(LibFunc::memset_pattern16);
ARM: teach backend about WatchOS and TvOS libcalls. The most substantial changes are again for watchOS: libcalls are hard-float if needed and sincos has a different calling convention. llvm-svn: 251571
2015-10-28 23:51:16 +01:00
} else if (!T.isWatchOS()) {
introduce a new TargetLibraryInfo pass, which transformations can use to query about available library functions. For now this just has memset_pattern16, which exists on darwin, but it can be extended for a bunch of other things in the future. llvm-svn: 125965
2011-02-18 22:50:34 +01:00
TLI.setUnavailable(LibFunc::memset_pattern16);
Target: Eliminate a use of getDarwinMajorNumber(). llvm-svn: 129803
2011-04-19 22:44:08 +02:00
}
Optimize printf -> iprintf if there are no floating point arguments and iprintf is available on the target. Currently iprintf is only marked as being available on the XCore. llvm-svn: 126935
2011-03-03 14:17:51 +01:00
Convert calls to __sinpi and __cospi into __sincospi_stret This adds an SimplifyLibCalls case which converts the special __sinpi and __cospi (float & double variants) into a __sincospi_stret where appropriate to remove duplicated work. Patch by Tim Northover llvm-svn: 193943
2013-11-03 07:48:38 +01:00
if (!hasSinCosPiStret(T)) {
TLI.setUnavailable(LibFunc::sinpi);
TLI.setUnavailable(LibFunc::sinpif);
TLI.setUnavailable(LibFunc::cospi);
TLI.setUnavailable(LibFunc::cospif);
TLI.setUnavailable(LibFunc::sincospi_stret);
OS X: the correct function is __sincospif_stret, not __sincospi_stretf rdar://problem/13729466 llvm-svn: 200771
2014-02-04 17:28:20 +01:00
TLI.setUnavailable(LibFunc::sincospif_stret);
Convert calls to __sinpi and __cospi into __sincospi_stret This adds an SimplifyLibCalls case which converts the special __sinpi and __cospi (float & double variants) into a __sincospi_stret where appropriate to remove duplicated work. Patch by Tim Northover llvm-svn: 193943
2013-11-03 07:48:38 +01:00
}
Add support for custom names for library functions in TargetLibraryInfo. Add a custom name for fwrite and fputs on x86-32 OSX. Make SimplifyLibCalls honor the custom names for fwrite and fputs. Fixes <rdar://problem/9815881>. llvm-svn: 144876
2011-11-17 02:27:36 +01: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.
TLI.setAvailableWithName(LibFunc::fwrite, "fwrite$UNIX2003");
TLI.setAvailableWithName(LibFunc::fputs, "fputs$UNIX2003");
}
Enable printf() to iprintf() optimization for the TCE target. Patch by Pekka Jaaskelainen. llvm-svn: 132774
2011-06-09 13:11:45 +02:00
// iprintf and friends are only available on XCore and TCE.
if (T.getArch() != Triple::xcore && T.getArch() != Triple::tce) {
Optimize printf -> iprintf if there are no floating point arguments and iprintf is available on the target. Currently iprintf is only marked as being available on the XCore. llvm-svn: 126935
2011-03-03 14:17:51 +01:00
TLI.setUnavailable(LibFunc::iprintf);
Optimize sprintf -> siprintf if there are no floating point arguments and siprintf is available on the target. llvm-svn: 126937
2011-03-03 15:09:28 +01:00
TLI.setUnavailable(LibFunc::siprintf);
Optimize fprintf -> iprintf if there are no floating point arguments and siprintf is available on the target. llvm-svn: 126940
2011-03-03 15:20:22 +01:00
TLI.setUnavailable(LibFunc::fiprintf);
Optimize sprintf -> siprintf if there are no floating point arguments and siprintf is available on the target. llvm-svn: 126937
2011-03-03 15:09:28 +01:00
}
fix pr12559: mark unavailable win32 math libcalls also fix SimplifyLibCalls to use TLI rather than compile-time conditionals to enable optimizations on floor, ceil, round, rint, and nearbyint llvm-svn: 154960
2012-04-18 01:05:54 +02:00
Target: invert condition for Windows The Microsoft ABI and MSVCRT are considered the canonical C runtime and ABI. The long double routines are not part of this environment. However, cygwin and MinGW both provide supplementary implementations. Change the condition to reflect this reality. llvm-svn: 213896
2014-07-25 00:09:06 +02:00
if (T.isOSWindows() && !T.isOSCygMing()) {
fix pr12559: mark unavailable win32 math libcalls also fix SimplifyLibCalls to use TLI rather than compile-time conditionals to enable optimizations on floor, ceil, round, rint, and nearbyint llvm-svn: 154960
2012-04-18 01:05:54 +02:00
// Win32 does not support long double
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);
Enable double to float shrinking optimizations for binary functions like 'fmin/fmax'. Fix radar:15283121 llvm-svn: 197434
2013-12-16 23:42:40 +01:00
TLI.setUnavailable(LibFunc::fmaxl);
TLI.setUnavailable(LibFunc::fminl);
fix pr12559: mark unavailable win32 math libcalls also fix SimplifyLibCalls to use TLI rather than compile-time conditionals to enable optimizations on floor, ceil, round, rint, and nearbyint llvm-svn: 154960
2012-04-18 01:05:54 +02:00
TLI.setUnavailable(LibFunc::fmodl);
Add more functions to the TLI. This patch adds many more functions to the target library information. All of the functions being added were discovered while doing the migration of the simplify-libcalls attribute annotation functionality to the functionattrs pass. As a part of that work the attribute annotation logic will query TLI to determine if a function should be annotated or not. Signed-off-by: Meador Inge <meadori@codesourcery.com> llvm-svn: 176514
2013-03-05 22:47:40 +01:00
TLI.setUnavailable(LibFunc::frexpl);
SimplifyLibCalls: Push TLI through the exp2->ldexp transform. For the odd case of platforms with exp2 available but not ldexp. llvm-svn: 200795
2014-02-04 21:27:23 +01:00
TLI.setUnavailable(LibFunc::ldexpf);
TLI.setUnavailable(LibFunc::ldexpl);
fix pr12559: mark unavailable win32 math libcalls also fix SimplifyLibCalls to use TLI rather than compile-time conditionals to enable optimizations on floor, ceil, round, rint, and nearbyint llvm-svn: 154960
2012-04-18 01:05:54 +02:00
TLI.setUnavailable(LibFunc::logl);
Add more functions to the TLI. This patch adds many more functions to the target library information. All of the functions being added were discovered while doing the migration of the simplify-libcalls attribute annotation functionality to the functionattrs pass. As a part of that work the attribute annotation logic will query TLI to determine if a function should be annotated or not. Signed-off-by: Meador Inge <meadori@codesourcery.com> llvm-svn: 176514
2013-03-05 22:47:40 +01:00
TLI.setUnavailable(LibFunc::modfl);
fix pr12559: mark unavailable win32 math libcalls also fix SimplifyLibCalls to use TLI rather than compile-time conditionals to enable optimizations on floor, ceil, round, rint, and nearbyint llvm-svn: 154960
2012-04-18 01:05:54 +02:00
TLI.setUnavailable(LibFunc::powl);
TLI.setUnavailable(LibFunc::sinl);
TLI.setUnavailable(LibFunc::sinhl);
TLI.setUnavailable(LibFunc::sqrtl);
TLI.setUnavailable(LibFunc::tanl);
TLI.setUnavailable(LibFunc::tanhl);
// Win32 only has C89 math
Add a few functions to TargetLibraryInfo as part of PR13574. Patch by Weiming Zhao <weimingz@codeaurora.org>. llvm-svn: 162329
2012-08-22 01:28:56 +02: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);
TLI.setUnavailable(LibFunc::cbrt);
TLI.setUnavailable(LibFunc::cbrtf);
TLI.setUnavailable(LibFunc::cbrtl);
fix pr12559: mark unavailable win32 math libcalls also fix SimplifyLibCalls to use TLI rather than compile-time conditionals to enable optimizations on floor, ceil, round, rint, and nearbyint llvm-svn: 154960
2012-04-18 01:05:54 +02:00
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);
Add a few functions to TargetLibraryInfo as part of PR13574. Patch by Weiming Zhao <weimingz@codeaurora.org>. llvm-svn: 162329
2012-08-22 01:28:56 +02:00
TLI.setUnavailable(LibFunc::logb);
TLI.setUnavailable(LibFunc::logbf);
TLI.setUnavailable(LibFunc::logbl);
fix pr12559: mark unavailable win32 math libcalls also fix SimplifyLibCalls to use TLI rather than compile-time conditionals to enable optimizations on floor, ceil, round, rint, and nearbyint llvm-svn: 154960
2012-04-18 01:05:54 +02:00
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);
// Win32 provides some C99 math with mangled names
TLI.setAvailableWithName(LibFunc::copysign, "_copysign");
if (T.getArch() == Triple::x86) {
// Win32 on x86 implements single-precision math functions as macros
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);
Enable double to float shrinking optimizations for binary functions like 'fmin/fmax'. Fix radar:15283121 llvm-svn: 197434
2013-12-16 23:42:40 +01:00
TLI.setUnavailable(LibFunc::fminf);
TLI.setUnavailable(LibFunc::fmaxf);
fix pr12559: mark unavailable win32 math libcalls also fix SimplifyLibCalls to use TLI rather than compile-time conditionals to enable optimizations on floor, ceil, round, rint, and nearbyint llvm-svn: 154960
2012-04-18 01:05:54 +02:00
TLI.setUnavailable(LibFunc::fmodf);
TLI.setUnavailable(LibFunc::logf);
[X86] Promote several single precision FP libcalls on Windows A number of libcalls don't exist in any particular lib but are, instead, defined in math.h as inline functions (even in C mode!). Don't rely on their existence when lowering @llvm.{cos,sin,floor,..}.f32, promote them instead. N.B. We had logic to handle FREM but were missing out on a number of others. This change generalizes the FREM handling. llvm-svn: 268875
2016-05-08 10:15:50 +02:00
TLI.setUnavailable(LibFunc::log10f);
TLI.setUnavailable(LibFunc::modff);
fix pr12559: mark unavailable win32 math libcalls also fix SimplifyLibCalls to use TLI rather than compile-time conditionals to enable optimizations on floor, ceil, round, rint, and nearbyint llvm-svn: 154960
2012-04-18 01:05:54 +02:00
TLI.setUnavailable(LibFunc::powf);
TLI.setUnavailable(LibFunc::sinf);
TLI.setUnavailable(LibFunc::sinhf);
TLI.setUnavailable(LibFunc::sqrtf);
TLI.setUnavailable(LibFunc::tanf);
TLI.setUnavailable(LibFunc::tanhf);
}
Add more functions to the target library information. In the process of migrating optimizations from the simplify-libcalls pass to the instcombine pass I noticed that a few functions are missing from the target library information. These functions need to be available for querying in the instcombine library call simplifiers. More functions will probably be added in the future as more simplifiers are migrated to instcombine. llvm-svn: 167659
2012-11-10 04:11:06 +01:00
Add more functions to the TLI. This patch adds many more functions to the target library information. All of the functions being added were discovered while doing the migration of the simplify-libcalls attribute annotation functionality to the functionattrs pass. As a part of that work the attribute annotation logic will query TLI to determine if a function should be annotated or not. Signed-off-by: Meador Inge <meadori@codesourcery.com> llvm-svn: 176514
2013-03-05 22:47:40 +01:00
// Win32 does *not* provide provide these functions, but they are
// generally available on POSIX-compliant systems:
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);
Add more functions to the target library information. I discovered a few more missing functions while migrating optimizations from the simplify-libcalls pass to the instcombine (I already added some in r167659). llvm-svn: 168501
2012-11-22 16:36:42 +01:00
TLI.setUnavailable(LibFunc::ffs);
Add more functions to the TLI. This patch adds many more functions to the target library information. All of the functions being added were discovered while doing the migration of the simplify-libcalls attribute annotation functionality to the functionattrs pass. As a part of that work the attribute annotation logic will query TLI to determine if a function should be annotated or not. Signed-off-by: Meador Inge <meadori@codesourcery.com> llvm-svn: 176514
2013-03-05 22:47:40 +01:00
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::getc_unlocked);
TLI.setUnavailable(LibFunc::getitimer);
TLI.setUnavailable(LibFunc::getlogin_r);
TLI.setUnavailable(LibFunc::getpwnam);
Added posix function gettimeofday to LibFunc::Func for all platforms but Windows. *NOTE* In a recent version of posix, they added the restrict keyword to the arguments for this function. From some spelunking it seems that on some platforms, the call has restrict on its arguments and others it does not. Thus I left off the restrict keyword from the function prototype in the comment. llvm-svn: 185501
2013-07-03 06:00:51 +02:00
TLI.setUnavailable(LibFunc::gettimeofday);
Add more functions to the TLI. This patch adds many more functions to the target library information. All of the functions being added were discovered while doing the migration of the simplify-libcalls attribute annotation functionality to the functionattrs pass. As a part of that work the attribute annotation logic will query TLI to determine if a function should be annotated or not. Signed-off-by: Meador Inge <meadori@codesourcery.com> llvm-svn: 176514
2013-03-05 22:47:40 +01:00
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);
Add more functions to the target library information. I discovered a few more missing functions while migrating optimizations from the simplify-libcalls pass to the instcombine (I already added some in r167659). llvm-svn: 168501
2012-11-22 16:36:42 +01:00
Add more functions to the TLI. This patch adds many more functions to the target library information. All of the functions being added were discovered while doing the migration of the simplify-libcalls attribute annotation functionality to the functionattrs pass. As a part of that work the attribute annotation logic will query TLI to determine if a function should be annotated or not. Signed-off-by: Meador Inge <meadori@codesourcery.com> llvm-svn: 176514
2013-03-05 22:47:40 +01:00
// Win32 does *not* provide provide these functions, but they are
// specified by C99:
TLI.setUnavailable(LibFunc::atoll);
TLI.setUnavailable(LibFunc::frexpf);
Add more functions to the target library information. I discovered a few more missing functions while migrating optimizations from the simplify-libcalls pass to the instcombine (I already added some in r167659). llvm-svn: 168501
2012-11-22 16:36:42 +01:00
TLI.setUnavailable(LibFunc::llabs);
TLI: Make exp10* avaiable on Linux/Mac/iOS and unavailable elsewhere This makes it unavailable on NetBSD, Android, etc. Patch by Brad Smith! llvm-svn: 198056
2013-12-26 20:17:04 +01:00
}
switch (T.getOS()) {
case Triple::MacOSX:
Disable transforms that introduce calls to exp10*() on Linux due to widespread glibc bugs. The glibc implementation of exp10 has a very serious precision bug in version 2.15 (and older versions). This is still very widely used (the current Ubuntu LTS for example uses it) and so it isn't reasonable to make transforms that produce these functions. This fixes many miscompiles introduced when we started transforming pow(10.0, ...) into exp10, and it may have fixed other latent miscompiles where exp10 provided sufficient precision but exp10f did not. This is all really horrible. The primary bug has been fixed for over a year and glibc 2.18 works correctly for the test cases I have, but it will be 2017 before the LTS using 2.15 is no longer supported by Ubuntu (and thus reasonable for folks to be relying on). =[ We're either going to need to live without these optimizations, or find a way to switch behavior more dynamically than using simply the fact that the OS is "Linux". To make matters worse, there appears to be significant testing and fixing of numerous other bugs in the exp10 family of functions right now in glibc. While those haven't been causing problems I've seen in the wild, it gives me concerns that we may need to wait until an even later release of glibc before we can reliably transform code into exp10. llvm-svn: 198093
2013-12-28 03:40:19 +01: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.
TLI: Make exp10* avaiable on Linux/Mac/iOS and unavailable elsewhere This makes it unavailable on NetBSD, Android, etc. Patch by Brad Smith! llvm-svn: 198056
2013-12-26 20:17:04 +01:00
TLI.setUnavailable(LibFunc::exp10l);
if (T.isMacOSXVersionLT(10, 9)) {
TLI.setUnavailable(LibFunc::exp10);
TLI.setUnavailable(LibFunc::exp10f);
} else {
TLI.setAvailableWithName(LibFunc::exp10, "__exp10");
TLI.setAvailableWithName(LibFunc::exp10f, "__exp10f");
}
break;
case Triple::IOS:
TvOS: add missing support for some libcalls. llvm-svn: 251811
2015-11-02 19:00:00 +01:00
case Triple::TvOS:
ARM: teach backend about WatchOS and TvOS libcalls. The most substantial changes are again for watchOS: libcalls are hard-float if needed and sincos has a different calling convention. llvm-svn: 251571
2015-10-28 23:51:16 +01:00
case Triple::WatchOS:
TLI: Make exp10* avaiable on Linux/Mac/iOS and unavailable elsewhere This makes it unavailable on NetBSD, Android, etc. Patch by Brad Smith! llvm-svn: 198056
2013-12-26 20:17:04 +01:00
TLI.setUnavailable(LibFunc::exp10l);
ARM: teach backend about WatchOS and TvOS libcalls. The most substantial changes are again for watchOS: libcalls are hard-float if needed and sincos has a different calling convention. llvm-svn: 251571
2015-10-28 23:51:16 +01:00
if (!T.isWatchOS() && (T.isOSVersionLT(7, 0) ||
(T.isOSVersionLT(9, 0) &&
(T.getArch() == Triple::x86 ||
T.getArch() == Triple::x86_64)))) {
TLI: Make exp10* avaiable on Linux/Mac/iOS and unavailable elsewhere This makes it unavailable on NetBSD, Android, etc. Patch by Brad Smith! llvm-svn: 198056
2013-12-26 20:17:04 +01:00
TLI.setUnavailable(LibFunc::exp10);
TLI.setUnavailable(LibFunc::exp10f);
} else {
TLI.setAvailableWithName(LibFunc::exp10, "__exp10");
TLI.setAvailableWithName(LibFunc::exp10f, "__exp10f");
}
break;
Disable transforms that introduce calls to exp10*() on Linux due to widespread glibc bugs. The glibc implementation of exp10 has a very serious precision bug in version 2.15 (and older versions). This is still very widely used (the current Ubuntu LTS for example uses it) and so it isn't reasonable to make transforms that produce these functions. This fixes many miscompiles introduced when we started transforming pow(10.0, ...) into exp10, and it may have fixed other latent miscompiles where exp10 provided sufficient precision but exp10f did not. This is all really horrible. The primary bug has been fixed for over a year and glibc 2.18 works correctly for the test cases I have, but it will be 2017 before the LTS using 2.15 is no longer supported by Ubuntu (and thus reasonable for folks to be relying on). =[ We're either going to need to live without these optimizations, or find a way to switch behavior more dynamically than using simply the fact that the OS is "Linux". To make matters worse, there appears to be significant testing and fixing of numerous other bugs in the exp10 family of functions right now in glibc. While those haven't been causing problems I've seen in the wild, it gives me concerns that we may need to wait until an even later release of glibc before we can reliably transform code into exp10. llvm-svn: 198093
2013-12-28 03:40:19 +01: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.
Replace a few more "fall through" comments with LLVM_FALLTHROUGH Follow up to r278902. I had missed "fall through", with a space. llvm-svn: 278970
2016-08-17 22:30:52 +02:00
LLVM_FALLTHROUGH;
TLI: Make exp10* avaiable on Linux/Mac/iOS and unavailable elsewhere This makes it unavailable on NetBSD, Android, etc. Patch by Brad Smith! llvm-svn: 198056
2013-12-26 20:17:04 +01:00
default:
TLI.setUnavailable(LibFunc::exp10);
TLI.setUnavailable(LibFunc::exp10f);
TLI.setUnavailable(LibFunc::exp10l);
Add more functions to the target library information. I discovered a few more missing functions while migrating optimizations from the simplify-libcalls pass to the instcombine (I already added some in r167659). llvm-svn: 168501
2012-11-22 16:36:42 +01: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
[LibraryInfo] Point to FreeBSD HEAD repo and not to a dolphin branch. The latter might go away (anytime soon). llvm-svn: 251765
2015-11-01 18:00:13 +01:00
// http://svn.freebsd.org/base/head/lib/libc/string/ffsl.c
Add more functions to the target library information. I discovered a few more missing functions while migrating optimizations from the simplify-libcalls pass to the instcombine (I already added some in r167659). llvm-svn: 168501
2012-11-22 16:36:42 +01:00
// http://www.gnu.org/software/gnulib/manual/html_node/ffsl.html
switch (T.getOS()) {
case Triple::Darwin:
case Triple::MacOSX:
case Triple::IOS:
TvOS: add missing support for some libcalls. llvm-svn: 251811
2015-11-02 19:00:00 +01:00
case Triple::TvOS:
ARM: teach backend about WatchOS and TvOS libcalls. The most substantial changes are again for watchOS: libcalls are hard-float if needed and sincos has a different calling convention. llvm-svn: 251571
2015-10-28 23:51:16 +01:00
case Triple::WatchOS:
Add more functions to the target library information. I discovered a few more missing functions while migrating optimizations from the simplify-libcalls pass to the instcombine (I already added some in r167659). llvm-svn: 168501
2012-11-22 16:36:42 +01:00
case Triple::FreeBSD:
case Triple::Linux:
break;
default:
TLI.setUnavailable(LibFunc::ffsl);
}
// ffsll is available on at least FreeBSD and Linux (GLIBC):
[LibraryInfo] Point to FreeBSD HEAD repo and not to a dolphin branch. The latter might go away (anytime soon). llvm-svn: 251765
2015-11-01 18:00:13 +01:00
// http://svn.freebsd.org/base/head/lib/libc/string/ffsll.c
Add more functions to the target library information. I discovered a few more missing functions while migrating optimizations from the simplify-libcalls pass to the instcombine (I already added some in r167659). llvm-svn: 168501
2012-11-22 16:36:42 +01:00
// http://www.gnu.org/software/gnulib/manual/html_node/ffsll.html
switch (T.getOS()) {
TvOS: add missing support for some libcalls. llvm-svn: 251811
2015-11-02 19:00:00 +01:00
case Triple::Darwin:
case Triple::MacOSX:
case Triple::IOS:
case Triple::TvOS:
case Triple::WatchOS:
Add more functions to the target library information. I discovered a few more missing functions while migrating optimizations from the simplify-libcalls pass to the instcombine (I already added some in r167659). llvm-svn: 168501
2012-11-22 16:36:42 +01:00
case Triple::FreeBSD:
case Triple::Linux:
break;
default:
TLI.setUnavailable(LibFunc::ffsll);
fix pr12559: mark unavailable win32 math libcalls also fix SimplifyLibCalls to use TLI rather than compile-time conditionals to enable optimizations on floor, ceil, round, rint, and nearbyint llvm-svn: 154960
2012-04-18 01:05:54 +02:00
}
Add more functions to the TLI. This patch adds many more functions to the target library information. All of the functions being added were discovered while doing the migration of the simplify-libcalls attribute annotation functionality to the functionattrs pass. As a part of that work the attribute annotation logic will query TLI to determine if a function should be annotated or not. Signed-off-by: Meador Inge <meadori@codesourcery.com> llvm-svn: 176514
2013-03-05 22:47:40 +01:00
[TargetLibraryInfo] Add support for fls, flsl, flsll. This is a prerequisite for further optimisations of these functions, which will be commited as a separate patch. Differential Revision: http://reviews.llvm.org/D14219 llvm-svn: 252535
2015-11-10 00:23:20 +01: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()) {
TLI.setUnavailable(LibFunc::fls);
TLI.setUnavailable(LibFunc::flsl);
TLI.setUnavailable(LibFunc::flsll);
}
Add more functions to the TLI. This patch adds many more functions to the target library information. All of the functions being added were discovered while doing the migration of the simplify-libcalls attribute annotation functionality to the functionattrs pass. As a part of that work the attribute annotation logic will query TLI to determine if a function should be annotated or not. Signed-off-by: Meador Inge <meadori@codesourcery.com> llvm-svn: 176514
2013-03-05 22:47:40 +01:00
// The following functions are available on at least Linux:
Clean up some usage of Triple. The base class has methods for determining if the target is iOS and Linux. llvm-svn: 189604
2013-08-29 22:23:14 +02:00
if (!T.isOSLinux()) {
Add more functions to the TLI. This patch adds many more functions to the target library information. All of the functions being added were discovered while doing the migration of the simplify-libcalls attribute annotation functionality to the functionattrs pass. As a part of that work the attribute annotation logic will query TLI to determine if a function should be annotated or not. Signed-off-by: Meador Inge <meadori@codesourcery.com> llvm-svn: 176514
2013-03-05 22:47:40 +01: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);
TLI.setUnavailable(LibFunc::memalign);
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);
}
TLI: Add addVectorizableFunctionsFromVecLib. Also, add several entries to vectorizable functions table, and corresponding tests. The table isn't complete, it'll be populated later. Review: http://reviews.llvm.org/D8131 llvm-svn: 232531
2015-03-17 20:50:55 +01:00
Disable all standard lib functions for NVVM. Summary: NVVM doesn't have a standard library, as currently implemented, so this just isn't going to work. I'd like to revisit this, since it's hiding opportunities for optimization, but correctness comes first. Thank you to hfinkel for pointing me in the right direction here. Reviewers: tra Subscribers: echristo, jhen, llvm-commits, hfinkel Differential Revision: http://reviews.llvm.org/D16604 llvm-svn: 258884
2016-01-27 00:51:06 +01: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.
[NVPTX] Infer __nvvm_reflect as nounwind, readnone This patch simply mirrors the attributes we give to @llvm.nvvm.reflect to the __nvvm_reflect libdevice call. This shaves about 30% of the code in libdevice away because of CSE opportunities. It's also helps us figure out that libdevice implementations of transcendental functions don't have side-effects. llvm-svn: 265060
2016-03-31 23:29:57 +02:00
if (T.isNVPTX()) {
Disable all standard lib functions for NVVM. Summary: NVVM doesn't have a standard library, as currently implemented, so this just isn't going to work. I'd like to revisit this, since it's hiding opportunities for optimization, but correctness comes first. Thank you to hfinkel for pointing me in the right direction here. Reviewers: tra Subscribers: echristo, jhen, llvm-commits, hfinkel Differential Revision: http://reviews.llvm.org/D16604 llvm-svn: 258884
2016-01-27 00:51:06 +01:00
TLI.disableAllFunctions();
[NVPTX] Infer __nvvm_reflect as nounwind, readnone This patch simply mirrors the attributes we give to @llvm.nvvm.reflect to the __nvvm_reflect libdevice call. This shaves about 30% of the code in libdevice away because of CSE opportunities. It's also helps us figure out that libdevice implementations of transcendental functions don't have side-effects. llvm-svn: 265060
2016-03-31 23:29:57 +02:00
TLI.setAvailable(LibFunc::nvvm_reflect);
} else {
TLI.setUnavailable(LibFunc::nvvm_reflect);
}
Disable all standard lib functions for NVVM. Summary: NVVM doesn't have a standard library, as currently implemented, so this just isn't going to work. I'd like to revisit this, since it's hiding opportunities for optimization, but correctness comes first. Thank you to hfinkel for pointing me in the right direction here. Reviewers: tra Subscribers: echristo, jhen, llvm-commits, hfinkel Differential Revision: http://reviews.llvm.org/D16604 llvm-svn: 258884
2016-01-27 00:51:06 +01:00
TLI: Add addVectorizableFunctionsFromVecLib. Also, add several entries to vectorizable functions table, and corresponding tests. The table isn't complete, it'll be populated later. Review: http://reviews.llvm.org/D8131 llvm-svn: 232531
2015-03-17 20:50:55 +01:00
TLI.addVectorizableFunctionsFromVecLib(ClVectorLibrary);
introduce a new TargetLibraryInfo pass, which transformations can use to query about available library functions. For now this just has memset_pattern16, which exists on darwin, but it can be extended for a bunch of other things in the future. llvm-svn: 125965
2011-02-18 22:50:34 +01: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 03:06:09 +01:00
TargetLibraryInfoImpl::TargetLibraryInfoImpl() {
introduce a new TargetLibraryInfo pass, which transformations can use to query about available library functions. For now this just has memset_pattern16, which exists on darwin, but it can be extended for a bunch of other things in the future. llvm-svn: 125965
2011-02-18 22:50:34 +01:00
// Default to everything being available.
memset(AvailableArray, -1, sizeof(AvailableArray));
Add new getLibFunc method to TargetLibraryInfo. This just provides a way to look up a LibFunc::Func enum value for a function name. Alphabetize the enums and function names so we can use a binary search. llvm-svn: 161231
2012-08-03 06:06:22 +02:00
initialize(*this, Triple(), StandardNames);
introduce a new TargetLibraryInfo pass, which transformations can use to query about available library functions. For now this just has memset_pattern16, which exists on darwin, but it can be extended for a bunch of other things in the future. llvm-svn: 125965
2011-02-18 22:50:34 +01: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 03:06:09 +01:00
TargetLibraryInfoImpl::TargetLibraryInfoImpl(const Triple &T) {
introduce a new TargetLibraryInfo pass, which transformations can use to query about available library functions. For now this just has memset_pattern16, which exists on darwin, but it can be extended for a bunch of other things in the future. llvm-svn: 125965
2011-02-18 22:50:34 +01:00
// Default to everything being available.
memset(AvailableArray, -1, sizeof(AvailableArray));
[PM] Separate the TargetLibraryInfo object from the immutable pass. The pass is really just a means of accessing a cached instance of the TargetLibraryInfo object, and this way we can re-use that object for the new pass manager as its result. Lots of delta, but nothing interesting happening here. This is the common pattern that is developing to allow analyses to live in both the old and new pass manager -- a wrapper pass in the old pass manager emulates the separation intrinsic to the new pass manager between the result and pass for analyses. llvm-svn: 226157
2015-01-15 11:41:28 +01:00
Add new getLibFunc method to TargetLibraryInfo. This just provides a way to look up a LibFunc::Func enum value for a function name. Alphabetize the enums and function names so we can use a binary search. llvm-svn: 161231
2012-08-03 06:06:22 +02:00
initialize(*this, T, StandardNames);
introduce a new TargetLibraryInfo pass, which transformations can use to query about available library functions. For now this just has memset_pattern16, which exists on darwin, but it can be extended for a bunch of other things in the future. llvm-svn: 125965
2011-02-18 22:50:34 +01:00
}
add a way to disable all builtins, wire it up to opt's -disable-simplifylibcalls flag. llvm-svn: 125978
2011-02-18 23:34:03 +01: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 03:06:09 +01:00
TargetLibraryInfoImpl::TargetLibraryInfoImpl(const TargetLibraryInfoImpl &TLI)
[TLI] Add functions determining if int parameters/returns should be zeroext/signext. On some architectures (s390x, ppc64, sparc64, mips), C-level int is passed as i32 signext instead of plain i32. Likewise, unsigned int may be passed as i32, i32 signext, or i32 zeroext depending on the platform. Add this information to TargetLibraryInfo, to be used whenever some LLVM pass inserts a compiler-rt call to a function involving int parameters or returns. Differential Revision: http://reviews.llvm.org/D21739 llvm-svn: 287533
2016-11-21 12:57:11 +01:00
: CustomNames(TLI.CustomNames), ShouldExtI32Param(TLI.ShouldExtI32Param),
ShouldExtI32Return(TLI.ShouldExtI32Return),
ShouldSignExtI32Param(TLI.ShouldSignExtI32Param) {
add a copy ctor to TargetLibraryInfo. llvm-svn: 131806
2011-05-21 22:09:13 +02:00
memcpy(AvailableArray, TLI.AvailableArray, sizeof(AvailableArray));
TLI: Add interface for querying whether a function is vectorizable. Review: http://reviews.llvm.org/D8093 llvm-svn: 232523
2015-03-17 20:22:30 +01:00
VectorDescs = TLI.VectorDescs;
ScalarDescs = TLI.ScalarDescs;
[PM] Port TargetLibraryInfo to the new pass manager, provided by the TargetLibraryAnalysis pass. There are actually no direct tests of this already in the tree. I've added the most basic test that the pass manager bits themselves work, and the TLI object produced will be tested by an upcoming patches as they port passes which rely on TLI. This is starting to point out the awkwardness of the invalidate API -- it seems poorly fitting on the *result* object. I suspect I will change it to live on the analysis instead, but that's not for this change, and I'd rather have a few more passes ported in order to have more experience with how this plays out. I believe there is only one more analysis required in order to start porting instcombine. =] llvm-svn: 226160
2015-01-15 12:39:46 +01: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 03:06:09 +01:00
TargetLibraryInfoImpl::TargetLibraryInfoImpl(TargetLibraryInfoImpl &&TLI)
[TLI] Add functions determining if int parameters/returns should be zeroext/signext. On some architectures (s390x, ppc64, sparc64, mips), C-level int is passed as i32 signext instead of plain i32. Likewise, unsigned int may be passed as i32, i32 signext, or i32 zeroext depending on the platform. Add this information to TargetLibraryInfo, to be used whenever some LLVM pass inserts a compiler-rt call to a function involving int parameters or returns. Differential Revision: http://reviews.llvm.org/D21739 llvm-svn: 287533
2016-11-21 12:57:11 +01:00
: CustomNames(std::move(TLI.CustomNames)),
ShouldExtI32Param(TLI.ShouldExtI32Param),
ShouldExtI32Return(TLI.ShouldExtI32Return),
ShouldSignExtI32Param(TLI.ShouldSignExtI32Param) {
[PM] Port TargetLibraryInfo to the new pass manager, provided by the TargetLibraryAnalysis pass. There are actually no direct tests of this already in the tree. I've added the most basic test that the pass manager bits themselves work, and the TLI object produced will be tested by an upcoming patches as they port passes which rely on TLI. This is starting to point out the awkwardness of the invalidate API -- it seems poorly fitting on the *result* object. I suspect I will change it to live on the analysis instead, but that's not for this change, and I'd rather have a few more passes ported in order to have more experience with how this plays out. I believe there is only one more analysis required in order to start porting instcombine. =] llvm-svn: 226160
2015-01-15 12:39:46 +01:00
std::move(std::begin(TLI.AvailableArray), std::end(TLI.AvailableArray),
AvailableArray);
TLI: Add interface for querying whether a function is vectorizable. Review: http://reviews.llvm.org/D8093 llvm-svn: 232523
2015-03-17 20:22:30 +01:00
VectorDescs = TLI.VectorDescs;
ScalarDescs = TLI.ScalarDescs;
[PM] Port TargetLibraryInfo to the new pass manager, provided by the TargetLibraryAnalysis pass. There are actually no direct tests of this already in the tree. I've added the most basic test that the pass manager bits themselves work, and the TLI object produced will be tested by an upcoming patches as they port passes which rely on TLI. This is starting to point out the awkwardness of the invalidate API -- it seems poorly fitting on the *result* object. I suspect I will change it to live on the analysis instead, but that's not for this change, and I'd rather have a few more passes ported in order to have more experience with how this plays out. I believe there is only one more analysis required in order to start porting instcombine. =] llvm-svn: 226160
2015-01-15 12:39:46 +01: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 03:06:09 +01:00
TargetLibraryInfoImpl &TargetLibraryInfoImpl::operator=(const TargetLibraryInfoImpl &TLI) {
Add support for custom names for library functions in TargetLibraryInfo. Add a custom name for fwrite and fputs on x86-32 OSX. Make SimplifyLibCalls honor the custom names for fwrite and fputs. Fixes <rdar://problem/9815881>. llvm-svn: 144876
2011-11-17 02:27:36 +01:00
CustomNames = TLI.CustomNames;
[TLI] Add functions determining if int parameters/returns should be zeroext/signext. On some architectures (s390x, ppc64, sparc64, mips), C-level int is passed as i32 signext instead of plain i32. Likewise, unsigned int may be passed as i32, i32 signext, or i32 zeroext depending on the platform. Add this information to TargetLibraryInfo, to be used whenever some LLVM pass inserts a compiler-rt call to a function involving int parameters or returns. Differential Revision: http://reviews.llvm.org/D21739 llvm-svn: 287533
2016-11-21 12:57:11 +01:00
ShouldExtI32Param = TLI.ShouldExtI32Param;
ShouldExtI32Return = TLI.ShouldExtI32Return;
ShouldSignExtI32Param = TLI.ShouldSignExtI32Param;
[PM] Port TargetLibraryInfo to the new pass manager, provided by the TargetLibraryAnalysis pass. There are actually no direct tests of this already in the tree. I've added the most basic test that the pass manager bits themselves work, and the TLI object produced will be tested by an upcoming patches as they port passes which rely on TLI. This is starting to point out the awkwardness of the invalidate API -- it seems poorly fitting on the *result* object. I suspect I will change it to live on the analysis instead, but that's not for this change, and I'd rather have a few more passes ported in order to have more experience with how this plays out. I believe there is only one more analysis required in order to start porting instcombine. =] llvm-svn: 226160
2015-01-15 12:39:46 +01: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 03:06:09 +01:00
TargetLibraryInfoImpl &TargetLibraryInfoImpl::operator=(TargetLibraryInfoImpl &&TLI) {
[PM] Port TargetLibraryInfo to the new pass manager, provided by the TargetLibraryAnalysis pass. There are actually no direct tests of this already in the tree. I've added the most basic test that the pass manager bits themselves work, and the TLI object produced will be tested by an upcoming patches as they port passes which rely on TLI. This is starting to point out the awkwardness of the invalidate API -- it seems poorly fitting on the *result* object. I suspect I will change it to live on the analysis instead, but that's not for this change, and I'd rather have a few more passes ported in order to have more experience with how this plays out. I believe there is only one more analysis required in order to start porting instcombine. =] llvm-svn: 226160
2015-01-15 12:39:46 +01:00
CustomNames = std::move(TLI.CustomNames);
[TLI] Add functions determining if int parameters/returns should be zeroext/signext. On some architectures (s390x, ppc64, sparc64, mips), C-level int is passed as i32 signext instead of plain i32. Likewise, unsigned int may be passed as i32, i32 signext, or i32 zeroext depending on the platform. Add this information to TargetLibraryInfo, to be used whenever some LLVM pass inserts a compiler-rt call to a function involving int parameters or returns. Differential Revision: http://reviews.llvm.org/D21739 llvm-svn: 287533
2016-11-21 12:57:11 +01:00
ShouldExtI32Param = TLI.ShouldExtI32Param;
ShouldExtI32Return = TLI.ShouldExtI32Return;
ShouldSignExtI32Param = TLI.ShouldSignExtI32Param;
[PM] Port TargetLibraryInfo to the new pass manager, provided by the TargetLibraryAnalysis pass. There are actually no direct tests of this already in the tree. I've added the most basic test that the pass manager bits themselves work, and the TLI object produced will be tested by an upcoming patches as they port passes which rely on TLI. This is starting to point out the awkwardness of the invalidate API -- it seems poorly fitting on the *result* object. I suspect I will change it to live on the analysis instead, but that's not for this change, and I'd rather have a few more passes ported in order to have more experience with how this plays out. I believe there is only one more analysis required in order to start porting instcombine. =] llvm-svn: 226160
2015-01-15 12:39:46 +01:00
std::move(std::begin(TLI.AvailableArray), std::end(TLI.AvailableArray),
AvailableArray);
return *this;
add a copy ctor to TargetLibraryInfo. llvm-svn: 131806
2011-05-21 22:09:13 +02:00
}
TLI: Factor out sanitizeFunctionName. NFC. llvm-svn: 231034
2015-03-03 00:24:40 +01:00
static StringRef sanitizeFunctionName(StringRef funcName) {
TLI: Microoptimize calls to strlen+memcmp to strncmp. The strlen+memcmp was hidden in a call to StringRef::operator==. We check if there are any null bytes in the string upfront so we can simplify the comparison Small speedup when compiling code with many function calls. llvm-svn: 176766
2013-03-09 14:48:23 +01: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)
TLI: Factor out sanitizeFunctionName. NFC. llvm-svn: 231034
2015-03-03 00:24:40 +01:00
return StringRef();
TLI: Microoptimize calls to strlen+memcmp to strncmp. The strlen+memcmp was hidden in a call to StringRef::operator==. We check if there are any null bytes in the string upfront so we can simplify the comparison Small speedup when compiling code with many function calls. llvm-svn: 176766
2013-03-09 14:48:23 +01:00
Add more functions to the TLI. This patch adds many more functions to the target library information. All of the functions being added were discovered while doing the migration of the simplify-libcalls attribute annotation functionality to the functionattrs pass. As a part of that work the attribute annotation logic will query TLI to determine if a function should be annotated or not. Signed-off-by: Meador Inge <meadori@codesourcery.com> llvm-svn: 176514
2013-03-05 22:47:40 +01:00
// Check for \01 prefix that is used to mangle __asm declarations and
// strip it if present.
[WinEH] Run cleanup handlers when an exception is thrown Generate tables in the .xdata section representing what actions to take when an exception is thrown. This currently fills in state for cleanups, catch handlers are still unfinished. llvm-svn: 233636
2015-03-31 00:58:10 +02:00
return GlobalValue::getRealLinkageName(funcName);
TLI: Factor out sanitizeFunctionName. NFC. llvm-svn: 231034
2015-03-03 00:24:40 +01:00
}
bool TargetLibraryInfoImpl::getLibFunc(StringRef funcName,
[TLI] Fix indentation. NFC. llvm-svn: 267757
2016-04-27 21:04:29 +02:00
LibFunc::Func &F) const {
Use StringRef in TLI instead of raw pointer (NFC) llvm-svn: 283005
2016-10-01 05:10:48 +02:00
StringRef const *Start = &StandardNames[0];
StringRef const *End = &StandardNames[LibFunc::NumLibFuncs];
TLI: Factor out sanitizeFunctionName. NFC. llvm-svn: 231034
2015-03-03 00:24:40 +01:00
funcName = sanitizeFunctionName(funcName);
if (funcName.empty())
return false;
Use StringRef in TLI instead of raw pointer (NFC) llvm-svn: 283005
2016-10-01 05:10:48 +02:00
StringRef const *I = std::lower_bound(
Start, End, funcName, [](StringRef LHS, StringRef RHS) {
return LHS < RHS;
TLI: Use lambda. NFC. llvm-svn: 231011
2015-03-02 21:50:08 +01:00
});
Add new getLibFunc method to TargetLibraryInfo. This just provides a way to look up a LibFunc::Func enum value for a function name. Alphabetize the enums and function names so we can use a binary search. llvm-svn: 161231
2012-08-03 06:06:22 +02:00
if (I != End && *I == funcName) {
F = (LibFunc::Func)(I - Start);
return true;
}
return false;
}
add a copy ctor to TargetLibraryInfo. llvm-svn: 131806
2011-05-21 22:09:13 +02:00
[TLI] Unify LibFunc signature checking. NFCI. I tried to be as close as possible to the strongest check that existed before; cleaning these up properly is left for future work. Differential Revision: http://reviews.llvm.org/D19469 llvm-svn: 267758
2016-04-27 21:04:35 +02:00
bool TargetLibraryInfoImpl::isValidProtoForLibFunc(const FunctionType &FTy,
LibFunc::Func F,
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) {
case LibFunc::strlen:
return (NumParams == 1 && FTy.getParamType(0)->isPointerTy() &&
FTy.getReturnType()->isIntegerTy());
case LibFunc::strchr:
case LibFunc::strrchr:
return (NumParams == 2 && FTy.getReturnType()->isPointerTy() &&
FTy.getParamType(0) == FTy.getReturnType() &&
FTy.getParamType(1)->isIntegerTy());
case LibFunc::strtol:
case LibFunc::strtod:
case LibFunc::strtof:
case LibFunc::strtoul:
case LibFunc::strtoll:
case LibFunc::strtold:
case LibFunc::strtoull:
return ((NumParams == 2 || NumParams == 3) &&
FTy.getParamType(0)->isPointerTy() &&
FTy.getParamType(1)->isPointerTy());
case LibFunc::strcat:
return (NumParams == 2 && FTy.getReturnType()->isPointerTy() &&
FTy.getParamType(0) == FTy.getReturnType() &&
FTy.getParamType(1) == FTy.getReturnType());
case LibFunc::strncat:
return (NumParams == 3 && FTy.getReturnType()->isPointerTy() &&
FTy.getParamType(0) == FTy.getReturnType() &&
FTy.getParamType(1) == FTy.getReturnType() &&
FTy.getParamType(2)->isIntegerTy());
case LibFunc::strcpy_chk:
case LibFunc::stpcpy_chk:
--NumParams;
if (!IsSizeTTy(FTy.getParamType(NumParams)))
return false;
Replace "fallthrough" comments with LLVM_FALLTHROUGH This is a mechanical change of comments in switches like fallthrough, fall-through, or fall-thru to use the LLVM_FALLTHROUGH macro instead. llvm-svn: 278902
2016-08-17 07:10:15 +02:00
LLVM_FALLTHROUGH;
[TLI] Unify LibFunc signature checking. NFCI. I tried to be as close as possible to the strongest check that existed before; cleaning these up properly is left for future work. Differential Revision: http://reviews.llvm.org/D19469 llvm-svn: 267758
2016-04-27 21:04:35 +02:00
case LibFunc::strcpy:
case LibFunc::stpcpy:
return (NumParams == 2 && FTy.getReturnType() == FTy.getParamType(0) &&
FTy.getParamType(0) == FTy.getParamType(1) &&
FTy.getParamType(0) == PCharTy);
case LibFunc::strncpy_chk:
case LibFunc::stpncpy_chk:
--NumParams;
if (!IsSizeTTy(FTy.getParamType(NumParams)))
return false;
Replace "fallthrough" comments with LLVM_FALLTHROUGH This is a mechanical change of comments in switches like fallthrough, fall-through, or fall-thru to use the LLVM_FALLTHROUGH macro instead. llvm-svn: 278902
2016-08-17 07:10:15 +02:00
LLVM_FALLTHROUGH;
[TLI] Unify LibFunc signature checking. NFCI. I tried to be as close as possible to the strongest check that existed before; cleaning these up properly is left for future work. Differential Revision: http://reviews.llvm.org/D19469 llvm-svn: 267758
2016-04-27 21:04:35 +02:00
case LibFunc::strncpy:
case LibFunc::stpncpy:
return (NumParams == 3 && FTy.getReturnType() == FTy.getParamType(0) &&
FTy.getParamType(0) == FTy.getParamType(1) &&
FTy.getParamType(0) == PCharTy &&
FTy.getParamType(2)->isIntegerTy());
case LibFunc::strxfrm:
return (NumParams == 3 && FTy.getParamType(0)->isPointerTy() &&
FTy.getParamType(1)->isPointerTy());
case LibFunc::strcmp:
return (NumParams == 2 && FTy.getReturnType()->isIntegerTy(32) &&
FTy.getParamType(0)->isPointerTy() &&
FTy.getParamType(0) == FTy.getParamType(1));
case LibFunc::strncmp:
return (NumParams == 3 && FTy.getReturnType()->isIntegerTy(32) &&
FTy.getParamType(0)->isPointerTy() &&
FTy.getParamType(0) == FTy.getParamType(1) &&
FTy.getParamType(2)->isIntegerTy());
case LibFunc::strspn:
case LibFunc::strcspn:
return (NumParams == 2 && FTy.getParamType(0)->isPointerTy() &&
FTy.getParamType(0) == FTy.getParamType(1) &&
FTy.getReturnType()->isIntegerTy());
case LibFunc::strcoll:
case LibFunc::strcasecmp:
case LibFunc::strncasecmp:
return (NumParams >= 2 && FTy.getParamType(0)->isPointerTy() &&
FTy.getParamType(1)->isPointerTy());
case LibFunc::strstr:
return (NumParams == 2 && FTy.getReturnType()->isPointerTy() &&
FTy.getParamType(0)->isPointerTy() &&
FTy.getParamType(1)->isPointerTy());
case LibFunc::strpbrk:
return (NumParams == 2 && FTy.getParamType(0)->isPointerTy() &&
FTy.getReturnType() == FTy.getParamType(0) &&
FTy.getParamType(0) == FTy.getParamType(1));
case LibFunc::strtok:
case LibFunc::strtok_r:
return (NumParams >= 2 && FTy.getParamType(1)->isPointerTy());
case LibFunc::scanf:
case LibFunc::setbuf:
case LibFunc::setvbuf:
return (NumParams >= 1 && FTy.getParamType(0)->isPointerTy());
case LibFunc::strdup:
case LibFunc::strndup:
return (NumParams >= 1 && FTy.getReturnType()->isPointerTy() &&
FTy.getParamType(0)->isPointerTy());
[TargetLibraryInfo] Reduce code duplication. llvm-svn: 273241
2016-06-21 06:32:21 +02:00
case LibFunc::sscanf:
[TLI] Unify LibFunc signature checking. NFCI. I tried to be as close as possible to the strongest check that existed before; cleaning these up properly is left for future work. Differential Revision: http://reviews.llvm.org/D19469 llvm-svn: 267758
2016-04-27 21:04:35 +02:00
case LibFunc::stat:
case LibFunc::statvfs:
case LibFunc::sprintf:
return (NumParams >= 2 && FTy.getParamType(0)->isPointerTy() &&
FTy.getParamType(1)->isPointerTy());
case LibFunc::snprintf:
return (NumParams == 3 && FTy.getParamType(0)->isPointerTy() &&
FTy.getParamType(2)->isPointerTy());
case LibFunc::setitimer:
return (NumParams == 3 && FTy.getParamType(1)->isPointerTy() &&
FTy.getParamType(2)->isPointerTy());
case LibFunc::system:
return (NumParams == 1 && FTy.getParamType(0)->isPointerTy());
case LibFunc::malloc:
return (NumParams == 1 && FTy.getReturnType()->isPointerTy());
case LibFunc::memcmp:
return (NumParams == 3 && FTy.getParamType(0)->isPointerTy() &&
FTy.getParamType(1)->isPointerTy() &&
FTy.getReturnType()->isIntegerTy(32));
case LibFunc::memchr:
case LibFunc::memrchr:
return (NumParams == 3 && FTy.getParamType(0)->isPointerTy() &&
FTy.getParamType(1)->isIntegerTy(32) &&
FTy.getParamType(2)->isIntegerTy() &&
FTy.getReturnType()->isPointerTy());
case LibFunc::modf:
case LibFunc::modff:
case LibFunc::modfl:
return (NumParams >= 2 && FTy.getParamType(1)->isPointerTy());
case LibFunc::memcpy_chk:
case LibFunc::memmove_chk:
--NumParams;
if (!IsSizeTTy(FTy.getParamType(NumParams)))
return false;
Replace "fallthrough" comments with LLVM_FALLTHROUGH This is a mechanical change of comments in switches like fallthrough, fall-through, or fall-thru to use the LLVM_FALLTHROUGH macro instead. llvm-svn: 278902
2016-08-17 07:10:15 +02:00
LLVM_FALLTHROUGH;
[TLI] Unify LibFunc signature checking. NFCI. I tried to be as close as possible to the strongest check that existed before; cleaning these up properly is left for future work. Differential Revision: http://reviews.llvm.org/D19469 llvm-svn: 267758
2016-04-27 21:04:35 +02:00
case LibFunc::memcpy:
Recommitting r275284: add support to inline __builtin_mempcpy Patch by Sunita Marathe Third try, now following fixes to MSan to handle mempcy in such a way that this commit won't break the MSan buildbots. (Thanks, Evegenii!) llvm-svn: 277189
2016-07-29 20:23:18 +02:00
case LibFunc::mempcpy:
[TLI] Unify LibFunc signature checking. NFCI. I tried to be as close as possible to the strongest check that existed before; cleaning these up properly is left for future work. Differential Revision: http://reviews.llvm.org/D19469 llvm-svn: 267758
2016-04-27 21:04:35 +02:00
case LibFunc::memmove:
return (NumParams == 3 && FTy.getReturnType() == FTy.getParamType(0) &&
FTy.getParamType(0)->isPointerTy() &&
FTy.getParamType(1)->isPointerTy() &&
IsSizeTTy(FTy.getParamType(2)));
case LibFunc::memset_chk:
--NumParams;
if (!IsSizeTTy(FTy.getParamType(NumParams)))
return false;
Replace "fallthrough" comments with LLVM_FALLTHROUGH This is a mechanical change of comments in switches like fallthrough, fall-through, or fall-thru to use the LLVM_FALLTHROUGH macro instead. llvm-svn: 278902
2016-08-17 07:10:15 +02:00
LLVM_FALLTHROUGH;
[TLI] Unify LibFunc signature checking. NFCI. I tried to be as close as possible to the strongest check that existed before; cleaning these up properly is left for future work. Differential Revision: http://reviews.llvm.org/D19469 llvm-svn: 267758
2016-04-27 21:04:35 +02:00
case LibFunc::memset:
return (NumParams == 3 && FTy.getReturnType() == FTy.getParamType(0) &&
FTy.getParamType(0)->isPointerTy() &&
FTy.getParamType(1)->isIntegerTy() &&
IsSizeTTy(FTy.getParamType(2)));
case LibFunc::memccpy:
return (NumParams >= 2 && FTy.getParamType(1)->isPointerTy());
case LibFunc::memalign:
return (FTy.getReturnType()->isPointerTy());
case LibFunc::realloc:
return (NumParams == 2 && FTy.getParamType(0)->isPointerTy() &&
FTy.getReturnType()->isPointerTy());
case LibFunc::read:
return (NumParams == 3 && FTy.getParamType(1)->isPointerTy());
case LibFunc::rewind:
case LibFunc::rmdir:
case LibFunc::remove:
case LibFunc::realpath:
return (NumParams >= 1 && FTy.getParamType(0)->isPointerTy());
case LibFunc::rename:
return (NumParams >= 2 && FTy.getParamType(0)->isPointerTy() &&
FTy.getParamType(1)->isPointerTy());
case LibFunc::readlink:
return (NumParams >= 2 && FTy.getParamType(0)->isPointerTy() &&
FTy.getParamType(1)->isPointerTy());
case LibFunc::write:
return (NumParams == 3 && FTy.getParamType(1)->isPointerTy());
case LibFunc::bcopy:
case LibFunc::bcmp:
return (NumParams == 3 && FTy.getParamType(0)->isPointerTy() &&
FTy.getParamType(1)->isPointerTy());
case LibFunc::bzero:
return (NumParams == 2 && FTy.getParamType(0)->isPointerTy());
case LibFunc::calloc:
return (NumParams == 2 && FTy.getReturnType()->isPointerTy());
[TLI] Fix NumParams==0 prototype checking typo. There was a typo in r267758. It caused invalid accesses when given something like "void @free(...)", as NumParams == 0, and we then try to look at the 0th parameter. Turns out, most of these were untested; add both attribute and missing-prototype checks for all libc libfuncs. Differential Revision: http://reviews.llvm.org/D20543 llvm-svn: 270750
2016-05-25 22:22:45 +02:00
case LibFunc::atof:
[TLI] Unify LibFunc signature checking. NFCI. I tried to be as close as possible to the strongest check that existed before; cleaning these up properly is left for future work. Differential Revision: http://reviews.llvm.org/D19469 llvm-svn: 267758
2016-04-27 21:04:35 +02:00
case LibFunc::atoi:
case LibFunc::atol:
case LibFunc::atoll:
[TLI] Fix NumParams==0 prototype checking typo. There was a typo in r267758. It caused invalid accesses when given something like "void @free(...)", as NumParams == 0, and we then try to look at the 0th parameter. Turns out, most of these were untested; add both attribute and missing-prototype checks for all libc libfuncs. Differential Revision: http://reviews.llvm.org/D20543 llvm-svn: 270750
2016-05-25 22:22:45 +02:00
case LibFunc::ferror:
case LibFunc::getenv:
case LibFunc::getpwnam:
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:
[TLI] Unify LibFunc signature checking. NFCI. I tried to be as close as possible to the strongest check that existed before; cleaning these up properly is left for future work. Differential Revision: http://reviews.llvm.org/D19469 llvm-svn: 267758
2016-04-27 21:04:35 +02:00
return (NumParams == 1 && FTy.getParamType(0)->isPointerTy());
[TLI] Fix NumParams==0 prototype checking typo. There was a typo in r267758. It caused invalid accesses when given something like "void @free(...)", as NumParams == 0, and we then try to look at the 0th parameter. Turns out, most of these were untested; add both attribute and missing-prototype checks for all libc libfuncs. Differential Revision: http://reviews.llvm.org/D20543 llvm-svn: 270750
2016-05-25 22:22:45 +02:00
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:
case LibFunc::fileno:
case LibFunc::flockfile:
case LibFunc::free:
case LibFunc::fseek:
[TLI] Also cover Linux 64 libfunc (stat64, ...) prototype checking. My script missed those in r270750. llvm-svn: 270763
2016-05-25 23:16:33 +02:00
case LibFunc::fseeko64:
[TLI] Fix NumParams==0 prototype checking typo. There was a typo in r267758. It caused invalid accesses when given something like "void @free(...)", as NumParams == 0, and we then try to look at the 0th parameter. Turns out, most of these were untested; add both attribute and missing-prototype checks for all libc libfuncs. Differential Revision: http://reviews.llvm.org/D20543 llvm-svn: 270750
2016-05-25 22:22:45 +02:00
case LibFunc::fseeko:
case LibFunc::fsetpos:
case LibFunc::ftell:
[TLI] Also cover Linux 64 libfunc (stat64, ...) prototype checking. My script missed those in r270750. llvm-svn: 270763
2016-05-25 23:16:33 +02:00
case LibFunc::ftello64:
[TLI] Fix NumParams==0 prototype checking typo. There was a typo in r267758. It caused invalid accesses when given something like "void @free(...)", as NumParams == 0, and we then try to look at the 0th parameter. Turns out, most of these were untested; add both attribute and missing-prototype checks for all libc libfuncs. Differential Revision: http://reviews.llvm.org/D20543 llvm-svn: 270750
2016-05-25 22:22:45 +02:00
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:
return (NumParams != 0 && FTy.getParamType(0)->isPointerTy());
[TLI] Unify LibFunc signature checking. NFCI. I tried to be as close as possible to the strongest check that existed before; cleaning these up properly is left for future work. Differential Revision: http://reviews.llvm.org/D19469 llvm-svn: 267758
2016-04-27 21:04:35 +02:00
case LibFunc::access:
return (NumParams == 2 && FTy.getParamType(0)->isPointerTy());
case LibFunc::fopen:
return (NumParams == 2 && FTy.getReturnType()->isPointerTy() &&
FTy.getParamType(0)->isPointerTy() &&
FTy.getParamType(1)->isPointerTy());
case LibFunc::fdopen:
return (NumParams == 2 && FTy.getReturnType()->isPointerTy() &&
FTy.getParamType(1)->isPointerTy());
case LibFunc::fputc:
case LibFunc::fstat:
case LibFunc::frexp:
case LibFunc::frexpf:
case LibFunc::frexpl:
case LibFunc::fstatvfs:
return (NumParams == 2 && FTy.getParamType(1)->isPointerTy());
case LibFunc::fgets:
return (NumParams == 3 && FTy.getParamType(0)->isPointerTy() &&
FTy.getParamType(2)->isPointerTy());
case LibFunc::fread:
return (NumParams == 4 && FTy.getParamType(0)->isPointerTy() &&
FTy.getParamType(3)->isPointerTy());
case LibFunc::fwrite:
return (NumParams == 4 && FTy.getReturnType()->isIntegerTy() &&
FTy.getParamType(0)->isPointerTy() &&
FTy.getParamType(1)->isIntegerTy() &&
FTy.getParamType(2)->isIntegerTy() &&
FTy.getParamType(3)->isPointerTy());
case LibFunc::fputs:
return (NumParams >= 2 && FTy.getParamType(0)->isPointerTy() &&
FTy.getParamType(1)->isPointerTy());
case LibFunc::fscanf:
case LibFunc::fprintf:
return (NumParams >= 2 && FTy.getParamType(0)->isPointerTy() &&
FTy.getParamType(1)->isPointerTy());
case LibFunc::fgetpos:
return (NumParams >= 2 && FTy.getParamType(0)->isPointerTy() &&
FTy.getParamType(1)->isPointerTy());
case LibFunc::gets:
case LibFunc::getchar:
case LibFunc::getitimer:
return (NumParams == 2 && FTy.getParamType(1)->isPointerTy());
case LibFunc::ungetc:
return (NumParams == 2 && FTy.getParamType(1)->isPointerTy());
case LibFunc::utime:
case LibFunc::utimes:
return (NumParams == 2 && FTy.getParamType(0)->isPointerTy() &&
FTy.getParamType(1)->isPointerTy());
case LibFunc::putc:
return (NumParams == 2 && FTy.getParamType(1)->isPointerTy());
case LibFunc::pread:
case LibFunc::pwrite:
return (NumParams == 4 && FTy.getParamType(1)->isPointerTy());
case LibFunc::popen:
return (NumParams == 2 && FTy.getReturnType()->isPointerTy() &&
FTy.getParamType(0)->isPointerTy() &&
FTy.getParamType(1)->isPointerTy());
case LibFunc::vscanf:
return (NumParams == 2 && FTy.getParamType(1)->isPointerTy());
case LibFunc::vsscanf:
return (NumParams == 3 && FTy.getParamType(1)->isPointerTy() &&
FTy.getParamType(2)->isPointerTy());
case LibFunc::vfscanf:
return (NumParams == 3 && FTy.getParamType(1)->isPointerTy() &&
FTy.getParamType(2)->isPointerTy());
case LibFunc::valloc:
return (FTy.getReturnType()->isPointerTy());
case LibFunc::vprintf:
return (NumParams == 2 && FTy.getParamType(0)->isPointerTy());
case LibFunc::vfprintf:
case LibFunc::vsprintf:
return (NumParams == 3 && FTy.getParamType(0)->isPointerTy() &&
FTy.getParamType(1)->isPointerTy());
case LibFunc::vsnprintf:
return (NumParams == 4 && FTy.getParamType(0)->isPointerTy() &&
FTy.getParamType(2)->isPointerTy());
case LibFunc::open:
return (NumParams >= 2 && FTy.getParamType(0)->isPointerTy());
case LibFunc::opendir:
return (NumParams == 1 && FTy.getReturnType()->isPointerTy() &&
FTy.getParamType(0)->isPointerTy());
case LibFunc::tmpfile:
return (FTy.getReturnType()->isPointerTy());
case LibFunc::htonl:
case LibFunc::htons:
case LibFunc::ntohl:
case LibFunc::ntohs:
case LibFunc::lstat:
return (NumParams == 2 && FTy.getParamType(0)->isPointerTy() &&
FTy.getParamType(1)->isPointerTy());
case LibFunc::lchown:
return (NumParams == 3 && FTy.getParamType(0)->isPointerTy());
case LibFunc::qsort:
return (NumParams == 4 && FTy.getParamType(3)->isPointerTy());
case LibFunc::dunder_strdup:
case LibFunc::dunder_strndup:
return (NumParams >= 1 && FTy.getReturnType()->isPointerTy() &&
FTy.getParamType(0)->isPointerTy());
case LibFunc::dunder_strtok_r:
return (NumParams == 3 && FTy.getParamType(1)->isPointerTy());
case LibFunc::under_IO_putc:
return (NumParams == 2 && FTy.getParamType(1)->isPointerTy());
case LibFunc::dunder_isoc99_scanf:
return (NumParams >= 1 && FTy.getParamType(0)->isPointerTy());
case LibFunc::stat64:
case LibFunc::lstat64:
case LibFunc::statvfs64:
[InferAttributes] Don't access parameters that don't exist. Check for the correct number of parameters before querying their type. This fixes PR30455. llvm-svn: 282038
2016-09-21 01:10:31 +02:00
return (NumParams == 2 && FTy.getParamType(0)->isPointerTy() &&
[TLI] Unify LibFunc signature checking. NFCI. I tried to be as close as possible to the strongest check that existed before; cleaning these up properly is left for future work. Differential Revision: http://reviews.llvm.org/D19469 llvm-svn: 267758
2016-04-27 21:04:35 +02:00
FTy.getParamType(1)->isPointerTy());
case LibFunc::dunder_isoc99_sscanf:
[InferAttributes] Don't access parameters that don't exist. Check for the correct number of parameters before querying their type. This fixes PR30455. llvm-svn: 282038
2016-09-21 01:10:31 +02:00
return (NumParams >= 2 && FTy.getParamType(0)->isPointerTy() &&
[TLI] Unify LibFunc signature checking. NFCI. I tried to be as close as possible to the strongest check that existed before; cleaning these up properly is left for future work. Differential Revision: http://reviews.llvm.org/D19469 llvm-svn: 267758
2016-04-27 21:04:35 +02:00
FTy.getParamType(1)->isPointerTy());
case LibFunc::fopen64:
return (NumParams == 2 && FTy.getReturnType()->isPointerTy() &&
FTy.getParamType(0)->isPointerTy() &&
FTy.getParamType(1)->isPointerTy());
case LibFunc::tmpfile64:
return (FTy.getReturnType()->isPointerTy());
case LibFunc::fstat64:
case LibFunc::fstatvfs64:
return (NumParams == 2 && FTy.getParamType(1)->isPointerTy());
case LibFunc::open64:
return (NumParams >= 2 && FTy.getParamType(0)->isPointerTy());
case LibFunc::gettimeofday:
return (NumParams == 2 && FTy.getParamType(0)->isPointerTy() &&
FTy.getParamType(1)->isPointerTy());
case LibFunc::Znwj: // new(unsigned int);
case LibFunc::Znwm: // new(unsigned long);
case LibFunc::Znaj: // new[](unsigned int);
case LibFunc::Znam: // new[](unsigned long);
case LibFunc::msvc_new_int: // new(unsigned int);
case LibFunc::msvc_new_longlong: // new(unsigned long long);
case LibFunc::msvc_new_array_int: // new[](unsigned int);
case LibFunc::msvc_new_array_longlong: // new[](unsigned long long);
return (NumParams == 1);
case LibFunc::memset_pattern16:
return (!FTy.isVarArg() && NumParams == 3 &&
isa<PointerType>(FTy.getParamType(0)) &&
isa<PointerType>(FTy.getParamType(1)) &&
isa<IntegerType>(FTy.getParamType(2)));
// int __nvvm_reflect(const char *);
case LibFunc::nvvm_reflect:
return (NumParams == 1 && isa<PointerType>(FTy.getParamType(0)));
case LibFunc::sin:
case LibFunc::sinf:
case LibFunc::sinl:
case LibFunc::cos:
case LibFunc::cosf:
case LibFunc::cosl:
[TargetLibraryInfo] Teach isValidProtoForLibFunc about tan We would fail to validate the type of the tan function which would cause downstream users of isValidProtoForLibFunc to assert. This fixes PR28143. llvm-svn: 272802
2016-06-15 18:47:23 +02:00
case LibFunc::tan:
case LibFunc::tanf:
case LibFunc::tanl:
[TLI] Unify LibFunc signature checking. NFCI. I tried to be as close as possible to the strongest check that existed before; cleaning these up properly is left for future work. Differential Revision: http://reviews.llvm.org/D19469 llvm-svn: 267758
2016-04-27 21:04:35 +02:00
case LibFunc::exp:
case LibFunc::expf:
case LibFunc::expl:
case LibFunc::exp2:
case LibFunc::exp2f:
case LibFunc::exp2l:
case LibFunc::log:
case LibFunc::logf:
case LibFunc::logl:
case LibFunc::log10:
case LibFunc::log10f:
case LibFunc::log10l:
case LibFunc::log2:
case LibFunc::log2f:
case LibFunc::log2l:
case LibFunc::fabs:
case LibFunc::fabsf:
case LibFunc::fabsl:
case LibFunc::floor:
case LibFunc::floorf:
case LibFunc::floorl:
case LibFunc::ceil:
case LibFunc::ceilf:
case LibFunc::ceill:
case LibFunc::trunc:
case LibFunc::truncf:
case LibFunc::truncl:
case LibFunc::rint:
case LibFunc::rintf:
case LibFunc::rintl:
case LibFunc::nearbyint:
case LibFunc::nearbyintf:
case LibFunc::nearbyintl:
case LibFunc::round:
case LibFunc::roundf:
case LibFunc::roundl:
case LibFunc::sqrt:
case LibFunc::sqrtf:
case LibFunc::sqrtl:
return (NumParams == 1 && FTy.getReturnType()->isFloatingPointTy() &&
FTy.getReturnType() == FTy.getParamType(0));
case LibFunc::fmin:
case LibFunc::fminf:
case LibFunc::fminl:
case LibFunc::fmax:
case LibFunc::fmaxf:
case LibFunc::fmaxl:
case LibFunc::copysign:
case LibFunc::copysignf:
case LibFunc::copysignl:
case LibFunc::pow:
case LibFunc::powf:
case LibFunc::powl:
return (NumParams == 2 && FTy.getReturnType()->isFloatingPointTy() &&
FTy.getReturnType() == FTy.getParamType(0) &&
FTy.getReturnType() == FTy.getParamType(1));
case LibFunc::ffs:
case LibFunc::ffsl:
case LibFunc::ffsll:
[TLI] isdigit / isascii / toascii param type should match return type (PR30484) We crash in LibCallSimplifier if we don't check the validity of the function signature properly. llvm-svn: 282278
2016-09-23 20:44:09 +02:00
return (NumParams == 1 && FTy.getReturnType()->isIntegerTy(32) &&
FTy.getParamType(0)->isIntegerTy());
[TLI] Unify LibFunc signature checking. NFCI. I tried to be as close as possible to the strongest check that existed before; cleaning these up properly is left for future work. Differential Revision: http://reviews.llvm.org/D19469 llvm-svn: 267758
2016-04-27 21:04:35 +02:00
case LibFunc::isdigit:
case LibFunc::isascii:
case LibFunc::toascii:
return (NumParams == 1 && FTy.getReturnType()->isIntegerTy(32) &&
[TLI] isdigit / isascii / toascii param type should match return type (PR30484) We crash in LibCallSimplifier if we don't check the validity of the function signature properly. llvm-svn: 282278
2016-09-23 20:44:09 +02:00
FTy.getReturnType() == FTy.getParamType(0));
[TLI] Unify LibFunc signature checking. NFCI. I tried to be as close as possible to the strongest check that existed before; cleaning these up properly is left for future work. Differential Revision: http://reviews.llvm.org/D19469 llvm-svn: 267758
2016-04-27 21:04:35 +02:00
case LibFunc::fls:
case LibFunc::flsl:
case LibFunc::flsll:
case LibFunc::abs:
case LibFunc::labs:
case LibFunc::llabs:
return (NumParams == 1 && FTy.getReturnType()->isIntegerTy() &&
FTy.getReturnType() == FTy.getParamType(0));
case LibFunc::cxa_atexit:
return (NumParams == 3 && FTy.getReturnType()->isIntegerTy() &&
FTy.getParamType(0)->isPointerTy() &&
FTy.getParamType(1)->isPointerTy() &&
FTy.getParamType(2)->isPointerTy());
case LibFunc::sinpi:
case LibFunc::cospi:
return (NumParams == 1 && FTy.getReturnType()->isDoubleTy() &&
FTy.getReturnType() == FTy.getParamType(0));
case LibFunc::sinpif:
case LibFunc::cospif:
return (NumParams == 1 && FTy.getReturnType()->isFloatTy() &&
FTy.getReturnType() == FTy.getParamType(0));
default:
// Assume the other functions are correct.
// FIXME: It'd be really nice to cover them all.
return true;
}
}
bool TargetLibraryInfoImpl::getLibFunc(const Function &FDecl,
LibFunc::Func &F) const {
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 03:06:09 +01:00
void TargetLibraryInfoImpl::disableAllFunctions() {
add a way to disable all builtins, wire it up to opt's -disable-simplifylibcalls flag. llvm-svn: 125978
2011-02-18 23:34:03 +01:00
memset(AvailableArray, 0, sizeof(AvailableArray));
}
[PM] Separate the TargetLibraryInfo object from the immutable pass. The pass is really just a means of accessing a cached instance of the TargetLibraryInfo object, and this way we can re-use that object for the new pass manager as its result. Lots of delta, but nothing interesting happening here. This is the common pattern that is developing to allow analyses to live in both the old and new pass manager -- a wrapper pass in the old pass manager emulates the separation intrinsic to the new pass manager between the result and pass for analyses. llvm-svn: 226157
2015-01-15 11:41:28 +01:00
TLI: Add interface for querying whether a function is vectorizable. Review: http://reviews.llvm.org/D8093 llvm-svn: 232523
2015-03-17 20:22:30 +01:00
static bool compareByScalarFnName(const VecDesc &LHS, const VecDesc &RHS) {
Use StringRef in TLI instead of raw pointer (NFC) llvm-svn: 283005
2016-10-01 05:10:48 +02:00
return LHS.ScalarFnName < RHS.ScalarFnName;
TLI: Add interface for querying whether a function is vectorizable. Review: http://reviews.llvm.org/D8093 llvm-svn: 232523
2015-03-17 20:22:30 +01:00
}
static bool compareByVectorFnName(const VecDesc &LHS, const VecDesc &RHS) {
Use StringRef in TLI instead of raw pointer (NFC) llvm-svn: 283005
2016-10-01 05:10:48 +02:00
return LHS.VectorFnName < RHS.VectorFnName;
TLI: Add interface for querying whether a function is vectorizable. Review: http://reviews.llvm.org/D8093 llvm-svn: 232523
2015-03-17 20:22:30 +01:00
}
static bool compareWithScalarFnName(const VecDesc &LHS, StringRef S) {
Use StringRef in TLI instead of raw pointer (NFC) llvm-svn: 283005
2016-10-01 05:10:48 +02:00
return LHS.ScalarFnName < S;
TLI: Add interface for querying whether a function is vectorizable. Review: http://reviews.llvm.org/D8093 llvm-svn: 232523
2015-03-17 20:22:30 +01:00
}
static bool compareWithVectorFnName(const VecDesc &LHS, StringRef S) {
Use StringRef in TLI instead of raw pointer (NFC) llvm-svn: 283005
2016-10-01 05:10:48 +02:00
return LHS.VectorFnName < S;
TLI: Add interface for querying whether a function is vectorizable. Review: http://reviews.llvm.org/D8093 llvm-svn: 232523
2015-03-17 20:22:30 +01:00
}
void TargetLibraryInfoImpl::addVectorizableFunctions(ArrayRef<VecDesc> Fns) {
VectorDescs.insert(VectorDescs.end(), Fns.begin(), Fns.end());
std::sort(VectorDescs.begin(), VectorDescs.end(), compareByScalarFnName);
ScalarDescs.insert(ScalarDescs.end(), Fns.begin(), Fns.end());
std::sort(ScalarDescs.begin(), ScalarDescs.end(), compareByVectorFnName);
}
TLI: Add addVectorizableFunctionsFromVecLib. Also, add several entries to vectorizable functions table, and corresponding tests. The table isn't complete, it'll be populated later. Review: http://reviews.llvm.org/D8131 llvm-svn: 232531
2015-03-17 20:50:55 +01:00
void TargetLibraryInfoImpl::addVectorizableFunctionsFromVecLib(
enum VectorLibrary VecLib) {
switch (VecLib) {
case Accelerate: {
const VecDesc VecFuncs[] = {
Populate list of vectorizable functions for Accelerate library. Summary: This patch adds majority of supported by Accelerate library functions to the list of vectorizable functions. The full list of available vector functions could be found here: https://developer.apple.com/library/mac/documentation/Performance/Conceptual/vecLib/index.html Test Plan: Unit tests are added. Reviewers: hfinkel, aschwaighofer, nadav Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9543 llvm-svn: 236747
2015-05-07 19:11:51 +02: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
TLI: Add addVectorizableFunctionsFromVecLib. Also, add several entries to vectorizable functions table, and corresponding tests. The table isn't complete, it'll be populated later. Review: http://reviews.llvm.org/D8131 llvm-svn: 232531
2015-03-17 20:50:55 +01:00
{"expf", "vexpf", 4},
{"llvm.exp.f32", "vexpf", 4},
Populate list of vectorizable functions for Accelerate library. Summary: This patch adds majority of supported by Accelerate library functions to the list of vectorizable functions. The full list of available vector functions could be found here: https://developer.apple.com/library/mac/documentation/Performance/Conceptual/vecLib/index.html Test Plan: Unit tests are added. Reviewers: hfinkel, aschwaighofer, nadav Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9543 llvm-svn: 236747
2015-05-07 19:11:51 +02:00
{"expm1f", "vexpm1f", 4},
TLI: Add addVectorizableFunctionsFromVecLib. Also, add several entries to vectorizable functions table, and corresponding tests. The table isn't complete, it'll be populated later. Review: http://reviews.llvm.org/D8131 llvm-svn: 232531
2015-03-17 20:50:55 +01:00
{"logf", "vlogf", 4},
{"llvm.log.f32", "vlogf", 4},
Populate list of vectorizable functions for Accelerate library. Summary: This patch adds majority of supported by Accelerate library functions to the list of vectorizable functions. The full list of available vector functions could be found here: https://developer.apple.com/library/mac/documentation/Performance/Conceptual/vecLib/index.html Test Plan: Unit tests are added. Reviewers: hfinkel, aschwaighofer, nadav Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9543 llvm-svn: 236747
2015-05-07 19:11:51 +02: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},
TLI: Add addVectorizableFunctionsFromVecLib. Also, add several entries to vectorizable functions table, and corresponding tests. The table isn't complete, it'll be populated later. Review: http://reviews.llvm.org/D8131 llvm-svn: 232531
2015-03-17 20:50:55 +01:00
};
addVectorizableFunctions(VecFuncs);
break;
}
Initial support for vectorization using svml (short vector math library). Differential Revision: https://reviews.llvm.org/D19544 llvm-svn: 277166
2016-07-29 18:42:44 +02: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},
{"cos", "__svml_cos2", 2},
{"cos", "__svml_cos4", 4},
{"cos", "__svml_cos8", 8},
{"cosf", "__svml_cosf4", 4},
{"cosf", "__svml_cosf8", 8},
{"cosf", "__svml_cosf16", 16},
{"pow", "__svml_pow2", 2},
{"pow", "__svml_pow4", 4},
{"pow", "__svml_pow8", 8},
{"powf", "__svml_powf4", 4},
{"powf", "__svml_powf8", 8},
{"powf", "__svml_powf16", 16},
{"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},
{"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},
{"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;
}
TLI: Add addVectorizableFunctionsFromVecLib. Also, add several entries to vectorizable functions table, and corresponding tests. The table isn't complete, it'll be populated later. Review: http://reviews.llvm.org/D8131 llvm-svn: 232531
2015-03-17 20:50:55 +01:00
case NoLibrary:
break;
}
}
TLI: Add interface for querying whether a function is vectorizable. Review: http://reviews.llvm.org/D8093 llvm-svn: 232523
2015-03-17 20:22:30 +01: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;
}
[PM] Remove support for omitting the AnalysisManager argument to new pass manager passes' `run` methods. This removes a bunch of SFINAE goop from the pass manager and just requires pass authors to accept `AnalysisManager<IRUnitT> &` as a dead argument. This is a small price to pay for the simplicity of the system as a whole, despite the noise that changing it causes at this stage. This will also helpfull allow us to make the signature of the run methods much more flexible for different kinds af passes to support things like intelligently updating the pass's progression over IR units. While this touches many, many, files, the changes are really boring. Mostly made with the help of my trusty perl one liners. Thanks to Sean and Hal for bouncing ideas for this with me in IRC. llvm-svn: 272978
2016-06-17 02:11:01 +02: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 03:06:09 +01:00
if (PresetInfoImpl)
return TargetLibraryInfo(*PresetInfoImpl);
return TargetLibraryInfo(lookupInfoImpl(Triple(M.getTargetTriple())));
}
[PM] Remove support for omitting the AnalysisManager argument to new pass manager passes' `run` methods. This removes a bunch of SFINAE goop from the pass manager and just requires pass authors to accept `AnalysisManager<IRUnitT> &` as a dead argument. This is a small price to pay for the simplicity of the system as a whole, despite the noise that changing it causes at this stage. This will also helpfull allow us to make the signature of the run methods much more flexible for different kinds af passes to support things like intelligently updating the pass's progression over IR units. While this touches many, many, files, the changes are really boring. Mostly made with the help of my trusty perl one liners. Thanks to Sean and Hal for bouncing ideas for this with me in IRC. llvm-svn: 272978
2016-06-17 02:11:01 +02: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 03:06:09 +01:00
if (PresetInfoImpl)
return TargetLibraryInfo(*PresetInfoImpl);
return TargetLibraryInfo(
lookupInfoImpl(Triple(F.getParent()->getTargetTriple())));
}
Apply most suggestions of clang-tidy's performance-unnecessary-value-param Avoids unnecessary copies. All changes audited & pass tests with asan. No functional change intended. llvm-svn: 272190
2016-06-08 21:09:22 +02: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 03:06:09 +01:00
std::unique_ptr<TargetLibraryInfoImpl> &Impl =
Impls[T.normalize()];
if (!Impl)
Impl.reset(new TargetLibraryInfoImpl(T));
return *Impl;
}
[PM] Separate the TargetLibraryInfo object from the immutable pass. The pass is really just a means of accessing a cached instance of the TargetLibraryInfo object, and this way we can re-use that object for the new pass manager as its result. Lots of delta, but nothing interesting happening here. This is the common pattern that is developing to allow analyses to live in both the old and new pass manager -- a wrapper pass in the old pass manager emulates the separation intrinsic to the new pass manager between the result and pass for analyses. llvm-svn: 226157
2015-01-15 11:41:28 +01: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 03:06:09 +01:00
: ImmutablePass(ID), TLIImpl(), TLI(TLIImpl) {
[PM] Separate the TargetLibraryInfo object from the immutable pass. The pass is really just a means of accessing a cached instance of the TargetLibraryInfo object, and this way we can re-use that object for the new pass manager as its result. Lots of delta, but nothing interesting happening here. This is the common pattern that is developing to allow analyses to live in both the old and new pass manager -- a wrapper pass in the old pass manager emulates the separation intrinsic to the new pass manager between the result and pass for analyses. llvm-svn: 226157
2015-01-15 11:41:28 +01: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 03:06:09 +01:00
: ImmutablePass(ID), TLIImpl(T), TLI(TLIImpl) {
[PM] Separate the TargetLibraryInfo object from the immutable pass. The pass is really just a means of accessing a cached instance of the TargetLibraryInfo object, and this way we can re-use that object for the new pass manager as its result. Lots of delta, but nothing interesting happening here. This is the common pattern that is developing to allow analyses to live in both the old and new pass manager -- a wrapper pass in the old pass manager emulates the separation intrinsic to the new pass manager between the result and pass for analyses. llvm-svn: 226157
2015-01-15 11:41:28 +01: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 03:06:09 +01:00
const TargetLibraryInfoImpl &TLIImpl)
: ImmutablePass(ID), TLIImpl(TLIImpl), TLI(this->TLIImpl) {
[PM] Separate the TargetLibraryInfo object from the immutable pass. The pass is really just a means of accessing a cached instance of the TargetLibraryInfo object, and this way we can re-use that object for the new pass manager as its result. Lots of delta, but nothing interesting happening here. This is the common pattern that is developing to allow analyses to live in both the old and new pass manager -- a wrapper pass in the old pass manager emulates the separation intrinsic to the new pass manager between the result and pass for analyses. llvm-svn: 226157
2015-01-15 11:41:28 +01:00
initializeTargetLibraryInfoWrapperPassPass(*PassRegistry::getPassRegistry());
}
[PM] Change the static object whose address is used to uniquely identify analyses to have a common type which is enforced rather than using a char object and a `void *` type when used as an identifier. This has a number of advantages. First, it at least helps some of the confusion raised in Justin Lebar's code review of why `void *` was being used everywhere by having a stronger type that connects to documentation about this. However, perhaps more importantly, it addresses a serious issue where the alignment of these pointer-like identifiers was unknown. This made it hard to use them in pointer-like data structures. We were already dodging this in dangerous ways to create the "all analyses" entry. In a subsequent patch I attempted to use these with TinyPtrVector and things fell apart in a very bad way. And it isn't just a compile time or type system issue. Worse than that, the actual alignment of these pointer-like opaque identifiers wasn't guaranteed to be a useful alignment as they were just characters. This change introduces a type to use as the "key" object whose address forms the opaque identifier. This both forces the objects to have proper alignment, and provides type checking that we get it right everywhere. It also makes the types somewhat less mysterious than `void *`. We could go one step further and introduce a truly opaque pointer-like type to return from the `ID()` static function rather than returning `AnalysisKey *`, but that didn't seem to be a clear win so this is just the initial change to get to a reliably typed and aligned object serving is a key for all the analyses. Thanks to Richard Smith and Justin Lebar for helping pick plausible names and avoid making this refactoring many times. =] And thanks to Sean for the super fast review! While here, I've tried to move away from the "PassID" nomenclature entirely as it wasn't really helping and is overloaded with old pass manager constructs. Now we have IDs for analyses, and key objects whose address can be used as IDs. Where possible and clear I've shortened this to just "ID". In a few places I kept "AnalysisID" to make it clear what was being identified. Differential Revision: https://reviews.llvm.org/D27031 llvm-svn: 287783
2016-11-23 18:53:26 +01:00
AnalysisKey TargetLibraryAnalysis::Key;
[PM] Appease mingw32's auto-import DLL build with minimal tweaks, with fix for clang. char AnalysisBase::ID should be declared as extern and defined in one module. llvm-svn: 262188
2016-02-28 18:17:00 +01:00
[PM] Separate the TargetLibraryInfo object from the immutable pass. The pass is really just a means of accessing a cached instance of the TargetLibraryInfo object, and this way we can re-use that object for the new pass manager as its result. Lots of delta, but nothing interesting happening here. This is the common pattern that is developing to allow analyses to live in both the old and new pass manager -- a wrapper pass in the old pass manager emulates the separation intrinsic to the new pass manager between the result and pass for analyses. llvm-svn: 226157
2015-01-15 11:41:28 +01:00
// Register the basic pass.
INITIALIZE_PASS(TargetLibraryInfoWrapperPass, "targetlibinfo",
"Target Library Information", false, true)
char TargetLibraryInfoWrapperPass::ID = 0;
void TargetLibraryInfoWrapperPass::anchor() {}
Reference in New Issue Copy Permalink