maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/lib/Analysis/TargetLibraryInfo.cpp

811 lines
22 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-19 05:50:34 +08:00
//===-- TargetLibraryInfo.cpp - Runtime library information ----------------==//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
// This file implements the TargetLibraryInfo class.
//
//===----------------------------------------------------------------------===//
[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 10:16:27 +08: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-19 05:50:34 +08:00
#include "llvm/ADT/Triple.h"
using namespace llvm;
[PM] Rework how the TargetLibraryInfo pass integrates with the new pass manager to support the actual uses of it. =] When I ported instcombine to the new pass manager I discover that it didn't work because TLI wasn't available in the right places. This is a somewhat surprising and/or subtle aspect of the new pass manager design that came up before but I think is useful to be reminded of: While the new pass manager *allows* a function pass to query a module analysis, it requires that the module analysis is already run and cached prior to the function pass manager starting up, possibly with a 'require<foo>' style utility in the pass pipeline. This is an intentional hurdle because using a module analysis from a function pass *requires* that the module analysis is run prior to entering the function pass manager. Otherwise the other functions in the module could be in who-knows-what state, etc. A somewhat surprising consequence of this design decision (at least to me) is that you have to design a function pass that leverages a module analysis to do so as an optional feature. Even if that means your function pass does no work in the absence of the module analysis, you have to handle that possibility and remain conservatively correct. This is a natural consequence of things being able to invalidate the module analysis and us being unable to re-run it. And it's a generally good thing because it lets us reorder passes arbitrarily without breaking correctness, etc. This ends up causing problems in one case. What if we have a module analysis that is *definitionally* impossible to invalidate. In the places this might come up, the analysis is usually also definitionally trivial to run even while other transformation passes run on the module, regardless of the state of anything. And so, it follows that it is natural to have a hard requirement on such analyses from a function pass. It turns out, that TargetLibraryInfo is just such an analysis, and InstCombine has a hard requirement on it. The approach I've taken here is to produce an analysis that models this flexibility by making it both a module and a function analysis. This exposes the fact that it is in fact safe to compute at any point. We can even make it a valid CGSCC analysis at some point if that is useful. However, we don't want to have a copy of the actual target library info state for each function! This state is specific to the triple. The somewhat direct and blunt approach here is to turn TLI into a pimpl, with the state and mutators in the implementation class and the query routines primarily in the wrapper. Then the analysis can lazily construct and cache the implementations, keyed on the triple, and on-demand produce wrappers of them for each function. One minor annoyance is that we will end up with a wrapper for each function in the module. While this is a bit wasteful (one pointer per function) it seems tolerable. And it has the advantage of ensuring that we pay the absolute minimum synchronization cost to access this information should we end up with a nice parallel function pass manager in the future. We could look into trying to mark when analysis results are especially cheap to recompute and more eagerly GC-ing the cached results, or we could look at supporting a variant of analyses whose results are specifically *not* cached and expected to just be used and discarded by the consumer. Either way, these seem like incremental enhancements that should happen when we start profiling the memory and CPU usage of the new pass manager and not before. The other minor annoyance is that if we end up using the TLI in both a module pass and a function pass, those will be produced by two separate analyses, and thus will point to separate copies of the implementation state. While a minor issue, I dislike this and would like to find a way to cleanly allow a single analysis instance to be used across multiple IR unit managers. But I don't have a good solution to this today, and I don't want to hold up all of the work waiting to come up with one. This too seems like a reasonable thing to incrementally improve later. llvm-svn: 226981
2015-01-24 10:06:09 +08:00
const char* TargetLibraryInfoImpl::StandardNames[LibFunc::NumLibFuncs] =
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 09:27:36 +08: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-06 05:47:40 +08:00
"_IO_getc",
"_IO_putc",
Make MemoryBuiltins aware of TargetLibraryInfo. This disables malloc-specific optimization when -fno-builtin (or -ffreestanding) is specified. This has been a problem for a long time but became more severe with the recent memory builtin improvements. Since the memory builtin functions are used everywhere, this required passing TLI in many places. This means that functions that now have an optional TLI argument, like RecursivelyDeleteTriviallyDeadFunctions, won't remove dead mallocs anymore if the TLI argument is missing. I've updated most passes to do the right thing. Fixes PR13694 and probably others. llvm-svn: 162841
2012-08-29 23:32:21 +08:00
"_ZdaPv",
Treat nothrow forms of ::operator delete and ::operator delete[] as deallocation functions. llvm-svn: 186798
2013-07-22 07:11:42 +08:00
"_ZdaPvRKSt9nothrow_t",
PR21145: Teach LLVM about C++14 sized deallocation functions. C++14 adds new builtin signatures for 'operator delete'. This change allows new/delete pairs to be removed in C++14 onwards, as they were in C++11 and before. llvm-svn: 219014
2014-10-04 04:17:06 +08:00
"_ZdaPvj",
"_ZdaPvm",
Make MemoryBuiltins aware of TargetLibraryInfo. This disables malloc-specific optimization when -fno-builtin (or -ffreestanding) is specified. This has been a problem for a long time but became more severe with the recent memory builtin improvements. Since the memory builtin functions are used everywhere, this required passing TLI in many places. This means that functions that now have an optional TLI argument, like RecursivelyDeleteTriviallyDeadFunctions, won't remove dead mallocs anymore if the TLI argument is missing. I've updated most passes to do the right thing. Fixes PR13694 and probably others. llvm-svn: 162841
2012-08-29 23:32:21 +08:00
"_ZdlPv",
Treat nothrow forms of ::operator delete and ::operator delete[] as deallocation functions. llvm-svn: 186798
2013-07-22 07:11:42 +08:00
"_ZdlPvRKSt9nothrow_t",
PR21145: Teach LLVM about C++14 sized deallocation functions. C++14 adds new builtin signatures for 'operator delete'. This change allows new/delete pairs to be removed in C++14 onwards, as they were in C++11 and before. llvm-svn: 219014
2014-10-04 04:17:06 +08:00
"_ZdlPvj",
"_ZdlPvm",
Make MemoryBuiltins aware of TargetLibraryInfo. This disables malloc-specific optimization when -fno-builtin (or -ffreestanding) is specified. This has been a problem for a long time but became more severe with the recent memory builtin improvements. Since the memory builtin functions are used everywhere, this required passing TLI in many places. This means that functions that now have an optional TLI argument, like RecursivelyDeleteTriviallyDeadFunctions, won't remove dead mallocs anymore if the TLI argument is missing. I've updated most passes to do the right thing. Fixes PR13694 and probably others. llvm-svn: 162841
2012-08-29 23:32:21 +08:00
"_Znaj",
"_ZnajRKSt9nothrow_t",
"_Znam",
"_ZnamRKSt9nothrow_t",
"_Znwj",
"_ZnwjRKSt9nothrow_t",
"_Znwm",
"_ZnwmRKSt9nothrow_t",
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 14:48:38 +08:00
"__cospi",
"__cospif",
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 12:06:22 +08:00
"__cxa_atexit",
"__cxa_guard_abort",
"__cxa_guard_acquire",
"__cxa_guard_release",
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-06 05:47:40 +08:00
"__isoc99_scanf",
"__isoc99_sscanf",
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 12:06:22 +08:00
"__memcpy_chk",
Add fortified (__*_chk) library functions to TLI (NFC) One of them (__memcpy_chk) was already there, the others were checked by comparing function names. Note that the fortified libfuncs are now part of TLI, but are always available, because they aren't generated, only optimized into the non-checking versions. Differential Revision: http://reviews.llvm.org/D6179 llvm-svn: 221817
2014-11-13 05:23:34 +08:00
"__memmove_chk",
"__memset_chk",
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 14:48:38 +08:00
"__sincospi_stret",
OS X: the correct function is __sincospif_stret, not __sincospi_stretf rdar://problem/13729466 llvm-svn: 200771
2014-02-05 00:28:20 +08:00
"__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 14:48:38 +08:00
"__sinpi",
"__sinpif",
Convert sqrt functions into sqrt instructions when -ffast-math is in effect. When -ffast-math is in effect (on Linux, at least), clang defines __FINITE_MATH_ONLY__ > 0 when including <math.h>. This causes the preprocessor to include <bits/math-finite.h>, which renames the sqrt functions. For instance, "sqrt" is renamed as "__sqrt_finite". This patch adds the 3 new names in such a way that they will be treated as equivalent to their respective original names. llvm-svn: 182739
2013-05-27 23:44:35 +08:00
"__sqrt_finite",
"__sqrtf_finite",
"__sqrtl_finite",
Add fortified (__*_chk) library functions to TLI (NFC) One of them (__memcpy_chk) was already there, the others were checked by comparing function names. Note that the fortified libfuncs are now part of TLI, but are always available, because they aren't generated, only optimized into the non-checking versions. Differential Revision: http://reviews.llvm.org/D6179 llvm-svn: 221817
2014-11-13 05:23:34 +08:00
"__stpcpy_chk",
"__stpncpy_chk",
"__strcpy_chk",
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-06 05:47:40 +08:00
"__strdup",
Add fortified (__*_chk) library functions to TLI (NFC) One of them (__memcpy_chk) was already there, the others were checked by comparing function names. Note that the fortified libfuncs are now part of TLI, but are always available, because they aren't generated, only optimized into the non-checking versions. Differential Revision: http://reviews.llvm.org/D6179 llvm-svn: 221817
2014-11-13 05:23:34 +08:00
"__strncpy_chk",
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-06 05:47:40 +08:00
"__strndup",
"__strtok_r",
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 23:36:42 +08:00
"abs",
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-06 05:47:40 +08:00
"access",
Add a few functions to TargetLibraryInfo. llvm-svn: 145508
2011-12-01 03:19:00 +08:00
"acos",
"acosf",
Add a few functions to TargetLibraryInfo as part of PR13574. Patch by Weiming Zhao <weimingz@codeaurora.org>. llvm-svn: 162329
2012-08-22 07:28:56 +08:00
"acosh",
"acoshf",
"acoshl",
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 12:06:22 +08:00
"acosl",
Add a few functions to TargetLibraryInfo. llvm-svn: 145508
2011-12-01 03:19:00 +08:00
"asin",
"asinf",
Add a few functions to TargetLibraryInfo as part of PR13574. Patch by Weiming Zhao <weimingz@codeaurora.org>. llvm-svn: 162329
2012-08-22 07:28:56 +08:00
"asinh",
"asinhf",
"asinhl",
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 12:06:22 +08:00
"asinl",
Add a few functions to TargetLibraryInfo. llvm-svn: 145508
2011-12-01 03:19:00 +08:00
"atan",
Add a few more functions to TargetLibraryInfo. More of rdar://10500969. llvm-svn: 145596
2011-12-02 01:54:37 +08:00
"atan2",
"atan2f",
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 12:06:22 +08:00
"atan2l",
"atanf",
Add a few functions to TargetLibraryInfo as part of PR13574. Patch by Weiming Zhao <weimingz@codeaurora.org>. llvm-svn: 162329
2012-08-22 07:28:56 +08:00
"atanh",
"atanhf",
"atanhl",
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 12:06:22 +08:00
"atanl",
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-06 05:47:40 +08:00
"atof",
"atoi",
"atol",
"atoll",
"bcmp",
"bcopy",
"bzero",
Make MemoryBuiltins aware of TargetLibraryInfo. This disables malloc-specific optimization when -fno-builtin (or -ffreestanding) is specified. This has been a problem for a long time but became more severe with the recent memory builtin improvements. Since the memory builtin functions are used everywhere, this required passing TLI in many places. This means that functions that now have an optional TLI argument, like RecursivelyDeleteTriviallyDeadFunctions, won't remove dead mallocs anymore if the TLI argument is missing. I've updated most passes to do the right thing. Fixes PR13694 and probably others. llvm-svn: 162841
2012-08-29 23:32:21 +08:00
"calloc",
Add a few functions to TargetLibraryInfo as part of PR13574. Patch by Weiming Zhao <weimingz@codeaurora.org>. llvm-svn: 162329
2012-08-22 07:28:56 +08:00
"cbrt",
"cbrtf",
"cbrtl",
Add a few functions to TargetLibraryInfo. llvm-svn: 145508
2011-12-01 03:19:00 +08:00
"ceil",
"ceilf",
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 12:06:22 +08:00
"ceill",
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-06 05:47:40 +08:00
"chmod",
"chown",
"clearerr",
"closedir",
Enhance both TargetLibraryInfo and SelectionDAGBuilder so that the latter can use the former to prevent the formation of libm SDNode's when -fno-builtin is passed. llvm-svn: 146193
2011-12-09 06:15:21 +08:00
"copysign",
"copysignf",
"copysignl",
Add a few functions to TargetLibraryInfo. llvm-svn: 145508
2011-12-01 03:19:00 +08:00
"cos",
"cosf",
"cosh",
"coshf",
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 12:06:22 +08:00
"coshl",
"cosl",
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-06 05:47:40 +08:00
"ctermid",
Add a few functions to TargetLibraryInfo. llvm-svn: 145508
2011-12-01 03:19:00 +08:00
"exp",
Add a few functions to TargetLibraryInfo as part of PR13574. Patch by Weiming Zhao <weimingz@codeaurora.org>. llvm-svn: 162329
2012-08-22 07:28:56 +08:00
"exp10",
"exp10f",
"exp10l",
Add a few functions to TargetLibraryInfo. llvm-svn: 145508
2011-12-01 03:19:00 +08:00
"exp2",
"exp2f",
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 12:06:22 +08:00
"exp2l",
"expf",
"expl",
Add a few functions to TargetLibraryInfo. llvm-svn: 145508
2011-12-01 03:19:00 +08:00
"expm1",
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 07:05:54 +08:00
"expm1f",
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 12:06:22 +08:00
"expm1l",
Add a few functions to TargetLibraryInfo. llvm-svn: 145508
2011-12-01 03:19:00 +08:00
"fabs",
"fabsf",
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 12:06:22 +08:00
"fabsl",
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-06 05:47:40 +08:00
"fclose",
"fdopen",
"feof",
"ferror",
"fflush",
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 23:36:42 +08:00
"ffs",
"ffsl",
"ffsll",
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-06 05:47:40 +08:00
"fgetc",
"fgetpos",
"fgets",
"fileno",
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 12:06:22 +08:00
"fiprintf",
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-06 05:47:40 +08:00
"flockfile",
Add a few functions to TargetLibraryInfo. llvm-svn: 145508
2011-12-01 03:19:00 +08:00
"floor",
"floorf",
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 12:06:22 +08:00
"floorl",
Enable double to float shrinking optimizations for binary functions like 'fmin/fmax'. Fix radar:15283121 llvm-svn: 197434
2013-12-17 06:42:40 +08:00
"fmax",
"fmaxf",
"fmaxl",
"fmin",
"fminf",
"fminl",
Add a few more functions to TargetLibraryInfo. More of rdar://10500969. llvm-svn: 145596
2011-12-02 01:54:37 +08:00
"fmod",
"fmodf",
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 12:06:22 +08:00
"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-06 05:47:40 +08:00
"fopen",
"fopen64",
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 23:36:42 +08:00
"fprintf",
add a few more functions to TargetLibraryInfo: fputc, memchr, memcmp, putchar, puts, strchr, strncmp llvm-svn: 160690
2012-07-25 05:00:36 +08:00
"fputc",
Alphabetize TargetLibraryInfo enum and fix doxygen comments. No functional change intended. llvm-svn: 145468
2011-11-30 09:51:49 +08:00
"fputs",
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-06 05:47:40 +08:00
"fread",
Make MemoryBuiltins aware of TargetLibraryInfo. This disables malloc-specific optimization when -fno-builtin (or -ffreestanding) is specified. This has been a problem for a long time but became more severe with the recent memory builtin improvements. Since the memory builtin functions are used everywhere, this required passing TLI in many places. This means that functions that now have an optional TLI argument, like RecursivelyDeleteTriviallyDeadFunctions, won't remove dead mallocs anymore if the TLI argument is missing. I've updated most passes to do the right thing. Fixes PR13694 and probably others. llvm-svn: 162841
2012-08-29 23:32:21 +08:00
"free",
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-06 05:47:40 +08:00
"frexp",
"frexpf",
"frexpl",
"fscanf",
"fseek",
"fseeko",
"fseeko64",
"fsetpos",
"fstat",
"fstat64",
"fstatvfs",
"fstatvfs64",
"ftell",
"ftello",
"ftello64",
"ftrylockfile",
"funlockfile",
Alphabetize TargetLibraryInfo enum and fix doxygen comments. No functional change intended. llvm-svn: 145468
2011-11-30 09:51:49 +08:00
"fwrite",
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-06 05:47:40 +08:00
"getc",
"getc_unlocked",
"getchar",
"getenv",
"getitimer",
"getlogin_r",
"getpwnam",
"gets",
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 12:00:51 +08:00
"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-06 05:47:40 +08:00
"htonl",
"htons",
Alphabetize TargetLibraryInfo enum and fix doxygen comments. No functional change intended. llvm-svn: 145468
2011-11-30 09:51:49 +08:00
"iprintf",
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 23:36:42 +08:00
"isascii",
"isdigit",
"labs",
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-06 05:47:40 +08:00
"lchown",
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-05 04:27:23 +08:00
"ldexp",
"ldexpf",
"ldexpl",
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 23:36:42 +08:00
"llabs",
Add a few functions to TargetLibraryInfo. llvm-svn: 145508
2011-12-01 03:19:00 +08:00
"log",
"log10",
"log10f",
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 12:06:22 +08:00
"log10l",
Add a few functions to TargetLibraryInfo. llvm-svn: 145508
2011-12-01 03:19:00 +08:00
"log1p",
"log1pf",
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 12:06:22 +08:00
"log1pl",
"log2",
"log2f",
"log2l",
Add a few functions to TargetLibraryInfo as part of PR13574. Patch by Weiming Zhao <weimingz@codeaurora.org>. llvm-svn: 162329
2012-08-22 07:28:56 +08:00
"logb",
"logbf",
"logbl",
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 12:06:22 +08:00
"logf",
"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-06 05:47:40 +08:00
"lstat",
"lstat64",
Make MemoryBuiltins aware of TargetLibraryInfo. This disables malloc-specific optimization when -fno-builtin (or -ffreestanding) is specified. This has been a problem for a long time but became more severe with the recent memory builtin improvements. Since the memory builtin functions are used everywhere, this required passing TLI in many places. This means that functions that now have an optional TLI argument, like RecursivelyDeleteTriviallyDeadFunctions, won't remove dead mallocs anymore if the TLI argument is missing. I've updated most passes to do the right thing. Fixes PR13694 and probably others. llvm-svn: 162841
2012-08-29 23:32:21 +08:00
"malloc",
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-06 05:47:40 +08:00
"memalign",
"memccpy",
add a few more functions to TargetLibraryInfo: fputc, memchr, memcmp, putchar, puts, strchr, strncmp llvm-svn: 160690
2012-07-25 05:00:36 +08:00
"memchr",
"memcmp",
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 09:27:36 +08:00
"memcpy",
"memmove",
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-06 05:47:40 +08:00
"memrchr",
Alphabetize TargetLibraryInfo enum and fix doxygen comments. No functional change intended. llvm-svn: 145468
2011-11-30 09:51:49 +08:00
"memset",
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 09:27:36 +08:00
"memset_pattern16",
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-06 05:47:40 +08:00
"mkdir",
"mktime",
"modf",
"modff",
"modfl",
Enhance both TargetLibraryInfo and SelectionDAGBuilder so that the latter can use the former to prevent the formation of libm SDNode's when -fno-builtin is passed. llvm-svn: 146193
2011-12-09 06:15:21 +08:00
"nearbyint",
"nearbyintf",
"nearbyintl",
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-06 05:47:40 +08:00
"ntohl",
"ntohs",
"open",
"open64",
"opendir",
"pclose",
"perror",
"popen",
Make MemoryBuiltins aware of TargetLibraryInfo. This disables malloc-specific optimization when -fno-builtin (or -ffreestanding) is specified. This has been a problem for a long time but became more severe with the recent memory builtin improvements. Since the memory builtin functions are used everywhere, this required passing TLI in many places. This means that functions that now have an optional TLI argument, like RecursivelyDeleteTriviallyDeadFunctions, won't remove dead mallocs anymore if the TLI argument is missing. I've updated most passes to do the right thing. Fixes PR13694 and probably others. llvm-svn: 162841
2012-08-29 23:32:21 +08:00
"posix_memalign",
Add a few functions to TargetLibraryInfo. llvm-svn: 145508
2011-12-01 03:19:00 +08:00
"pow",
"powf",
"powl",
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-06 05:47:40 +08:00
"pread",
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 23:36:42 +08:00
"printf",
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-06 05:47:40 +08:00
"putc",
add a few more functions to TargetLibraryInfo: fputc, memchr, memcmp, putchar, puts, strchr, strncmp llvm-svn: 160690
2012-07-25 05:00:36 +08:00
"putchar",
"puts",
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-06 05:47:40 +08:00
"pwrite",
"qsort",
"read",
"readlink",
Make MemoryBuiltins aware of TargetLibraryInfo. This disables malloc-specific optimization when -fno-builtin (or -ffreestanding) is specified. This has been a problem for a long time but became more severe with the recent memory builtin improvements. Since the memory builtin functions are used everywhere, this required passing TLI in many places. This means that functions that now have an optional TLI argument, like RecursivelyDeleteTriviallyDeadFunctions, won't remove dead mallocs anymore if the TLI argument is missing. I've updated most passes to do the right thing. Fixes PR13694 and probably others. llvm-svn: 162841
2012-08-29 23:32:21 +08:00
"realloc",
"reallocf",
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-06 05:47:40 +08:00
"realpath",
"remove",
"rename",
"rewind",
Enhance both TargetLibraryInfo and SelectionDAGBuilder so that the latter can use the former to prevent the formation of libm SDNode's when -fno-builtin is passed. llvm-svn: 146193
2011-12-09 06:15:21 +08:00
"rint",
"rintf",
"rintl",
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-06 05:47:40 +08:00
"rmdir",
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 07:05:54 +08:00
"round",
"roundf",
"roundl",
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-06 05:47:40 +08:00
"scanf",
"setbuf",
"setitimer",
"setvbuf",
Add a few more functions to TargetLibraryInfo. More of rdar://10500969. llvm-svn: 145596
2011-12-02 01:54:37 +08:00
"sin",
"sinf",
Add missing functions. llvm-svn: 145608
2011-12-02 02:26:19 +08:00
"sinh",
"sinhf",
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 12:06:22 +08:00
"sinhl",
"sinl",
Add missing functions. llvm-svn: 145608
2011-12-02 02:26:19 +08:00
"siprintf",
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-06 05:47:40 +08:00
"snprintf",
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 23:36:42 +08:00
"sprintf",
Add support for sqrt, sqrtl, and sqrtf in TargetLibraryInfo. Disable (fptrunc (sqrt (fpext x))) -> (sqrtf x) transformation if -fno-builtin is specified. rdar://10466410 llvm-svn: 145460
2011-11-30 07:57:10 +08:00
"sqrt",
Add a few more functions to TargetLibraryInfo. More of rdar://10500969. llvm-svn: 145596
2011-12-02 01:54:37 +08:00
"sqrtf",
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 12:06:22 +08:00
"sqrtl",
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-06 05:47:40 +08:00
"sscanf",
"stat",
"stat64",
"statvfs",
"statvfs64",
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 11:11:06 +08:00
"stpcpy",
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-06 05:47:40 +08:00
"stpncpy",
"strcasecmp",
TargetLibraryInfo: add strn?cat, strn?cpy, and strn?len llvm-svn: 160678
2012-07-25 01:25:06 +08:00
"strcat",
add a few more functions to TargetLibraryInfo: fputc, memchr, memcmp, putchar, puts, strchr, strncmp llvm-svn: 160690
2012-07-25 05:00:36 +08:00
"strchr",
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 11:11:06 +08:00
"strcmp",
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-06 05:47:40 +08:00
"strcoll",
TargetLibraryInfo: add strn?cat, strn?cpy, and strn?len llvm-svn: 160678
2012-07-25 01:25:06 +08:00
"strcpy",
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 11:11:06 +08:00
"strcspn",
Make MemoryBuiltins aware of TargetLibraryInfo. This disables malloc-specific optimization when -fno-builtin (or -ffreestanding) is specified. This has been a problem for a long time but became more severe with the recent memory builtin improvements. Since the memory builtin functions are used everywhere, this required passing TLI in many places. This means that functions that now have an optional TLI argument, like RecursivelyDeleteTriviallyDeadFunctions, won't remove dead mallocs anymore if the TLI argument is missing. I've updated most passes to do the right thing. Fixes PR13694 and probably others. llvm-svn: 162841
2012-08-29 23:32:21 +08:00
"strdup",
TargetLibraryInfo: add strn?cat, strn?cpy, and strn?len llvm-svn: 160678
2012-07-25 01:25:06 +08:00
"strlen",
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-06 05:47:40 +08:00
"strncasecmp",
TargetLibraryInfo: add strn?cat, strn?cpy, and strn?len llvm-svn: 160678
2012-07-25 01:25:06 +08:00
"strncat",
add a few more functions to TargetLibraryInfo: fputc, memchr, memcmp, putchar, puts, strchr, strncmp llvm-svn: 160690
2012-07-25 05:00:36 +08:00
"strncmp",
TargetLibraryInfo: add strn?cat, strn?cpy, and strn?len llvm-svn: 160678
2012-07-25 01:25:06 +08:00
"strncpy",
Make MemoryBuiltins aware of TargetLibraryInfo. This disables malloc-specific optimization when -fno-builtin (or -ffreestanding) is specified. This has been a problem for a long time but became more severe with the recent memory builtin improvements. Since the memory builtin functions are used everywhere, this required passing TLI in many places. This means that functions that now have an optional TLI argument, like RecursivelyDeleteTriviallyDeadFunctions, won't remove dead mallocs anymore if the TLI argument is missing. I've updated most passes to do the right thing. Fixes PR13694 and probably others. llvm-svn: 162841
2012-08-29 23:32:21 +08:00
"strndup",
TargetLibraryInfo: add strn?cat, strn?cpy, and strn?len llvm-svn: 160678
2012-07-25 01:25:06 +08:00
"strnlen",
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 11:11:06 +08:00
"strpbrk",
"strrchr",
"strspn",
"strstr",
"strtod",
"strtof",
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-06 05:47:40 +08:00
"strtok",
"strtok_r",
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 11:11:06 +08:00
"strtol",
"strtold",
"strtoll",
"strtoul",
"strtoull",
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-06 05:47:40 +08:00
"strxfrm",
"system",
Add a few more functions to TargetLibraryInfo. More of rdar://10500969. llvm-svn: 145596
2011-12-02 01:54:37 +08:00
"tan",
"tanf",
"tanh",
Enhance both TargetLibraryInfo and SelectionDAGBuilder so that the latter can use the former to prevent the formation of libm SDNode's when -fno-builtin is passed. llvm-svn: 146193
2011-12-09 06:15:21 +08:00
"tanhf",
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 12:06:22 +08:00
"tanhl",
"tanl",
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-06 05:47:40 +08:00
"times",
"tmpfile",
"tmpfile64",
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 23:36:42 +08:00
"toascii",
Enhance both TargetLibraryInfo and SelectionDAGBuilder so that the latter can use the former to prevent the formation of libm SDNode's when -fno-builtin is passed. llvm-svn: 146193
2011-12-09 06:15:21 +08:00
"trunc",
"truncf",
Make MemoryBuiltins aware of TargetLibraryInfo. This disables malloc-specific optimization when -fno-builtin (or -ffreestanding) is specified. This has been a problem for a long time but became more severe with the recent memory builtin improvements. Since the memory builtin functions are used everywhere, this required passing TLI in many places. This means that functions that now have an optional TLI argument, like RecursivelyDeleteTriviallyDeadFunctions, won't remove dead mallocs anymore if the TLI argument is missing. I've updated most passes to do the right thing. Fixes PR13694 and probably others. llvm-svn: 162841
2012-08-29 23:32:21 +08:00
"truncl",
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-06 05:47:40 +08:00
"uname",
"ungetc",
"unlink",
"unsetenv",
"utime",
"utimes",
"valloc",
"vfprintf",
"vfscanf",
"vprintf",
"vscanf",
"vsnprintf",
"vsprintf",
"vsscanf",
"write"
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 09:27:36 +08: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 14:48:38 +08: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 13:43:30 +08: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 14:48:38 +08:00
return false;
// The ABI is rather complicated on x86, so don't do anything special there.
if (T.getArch() == Triple::x86)
return false;
if (T.isMacOSX() && T.isMacOSXVersionLT(10, 9))
return false;
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 13:43:30 +08: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 14:48:38 +08: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-19 05:50:34 +08: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 10:06:09 +08:00
static void initialize(TargetLibraryInfoImpl &TLI, const Triple &T,
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 12:06:22 +08:00
const char **StandardNames) {
#ifndef NDEBUG
// Verify that the StandardNames array is in alphabetical order.
for (unsigned F = 1; F < LibFunc::NumLibFuncs; ++F) {
if (strcmp(StandardNames[F-1], StandardNames[F]) >= 0)
[PM] Rework how the TargetLibraryInfo pass integrates with the new pass manager to support the actual uses of it. =] When I ported instcombine to the new pass manager I discover that it didn't work because TLI wasn't available in the right places. This is a somewhat surprising and/or subtle aspect of the new pass manager design that came up before but I think is useful to be reminded of: While the new pass manager *allows* a function pass to query a module analysis, it requires that the module analysis is already run and cached prior to the function pass manager starting up, possibly with a 'require<foo>' style utility in the pass pipeline. This is an intentional hurdle because using a module analysis from a function pass *requires* that the module analysis is run prior to entering the function pass manager. Otherwise the other functions in the module could be in who-knows-what state, etc. A somewhat surprising consequence of this design decision (at least to me) is that you have to design a function pass that leverages a module analysis to do so as an optional feature. Even if that means your function pass does no work in the absence of the module analysis, you have to handle that possibility and remain conservatively correct. This is a natural consequence of things being able to invalidate the module analysis and us being unable to re-run it. And it's a generally good thing because it lets us reorder passes arbitrarily without breaking correctness, etc. This ends up causing problems in one case. What if we have a module analysis that is *definitionally* impossible to invalidate. In the places this might come up, the analysis is usually also definitionally trivial to run even while other transformation passes run on the module, regardless of the state of anything. And so, it follows that it is natural to have a hard requirement on such analyses from a function pass. It turns out, that TargetLibraryInfo is just such an analysis, and InstCombine has a hard requirement on it. The approach I've taken here is to produce an analysis that models this flexibility by making it both a module and a function analysis. This exposes the fact that it is in fact safe to compute at any point. We can even make it a valid CGSCC analysis at some point if that is useful. However, we don't want to have a copy of the actual target library info state for each function! This state is specific to the triple. The somewhat direct and blunt approach here is to turn TLI into a pimpl, with the state and mutators in the implementation class and the query routines primarily in the wrapper. Then the analysis can lazily construct and cache the implementations, keyed on the triple, and on-demand produce wrappers of them for each function. One minor annoyance is that we will end up with a wrapper for each function in the module. While this is a bit wasteful (one pointer per function) it seems tolerable. And it has the advantage of ensuring that we pay the absolute minimum synchronization cost to access this information should we end up with a nice parallel function pass manager in the future. We could look into trying to mark when analysis results are especially cheap to recompute and more eagerly GC-ing the cached results, or we could look at supporting a variant of analyses whose results are specifically *not* cached and expected to just be used and discarded by the consumer. Either way, these seem like incremental enhancements that should happen when we start profiling the memory and CPU usage of the new pass manager and not before. The other minor annoyance is that if we end up using the TLI in both a module pass and a function pass, those will be produced by two separate analyses, and thus will point to separate copies of the implementation state. While a minor issue, I dislike this and would like to find a way to cleanly allow a single analysis instance to be used across multiple IR unit managers. But I don't have a good solution to this today, and I don't want to hold up all of the work waiting to come up with one. This too seems like a reasonable thing to incrementally improve later. llvm-svn: 226981
2015-01-24 10:06:09 +08:00
llvm_unreachable("TargetLibraryInfoImpl function names must be sorted");
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 12:06:22 +08:00
}
#endif // !NDEBUG
TargetLibraryInfo: Disable memcpy and memset on R600 There are no implementations of these for R600. llvm-svn: 205455
2014-04-03 03:53:29 +08:00
R600/SI: Add check for amdgcn triple forgotten in r225276. llvm-svn: 225331
2015-01-07 09:17:37 +08: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-03 03:53:29 +08: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 09:17:37 +08:00
if (T.getArch() == Triple::r600 ||
T.getArch() == Triple::amdgcn) {
TargetLibraryInfo: Disable memcpy and memset on R600 There are no implementations of these for R600. llvm-svn: 205455
2014-04-03 03:53:29 +08: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-08 02:08:54 +08:00
// memset_pattern16 is only available on iOS 3.0 and Mac OS X 10.5 and later.
ADT/Triple: Renambe isOSX... methods to isMacOSX for consistency with the OS triple component. llvm-svn: 129838
2011-04-20 08:14:25 +08:00
if (T.isMacOSX()) {
if (T.isMacOSXVersionLT(10, 5))
Target: Eliminate a use of getDarwinMajorNumber(). llvm-svn: 129803
2011-04-20 04:44:08 +08: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-30 04:23:14 +08:00
} else if (T.isiOS()) {
Target: Eliminate a use of getDarwinMajorNumber(). llvm-svn: 129803
2011-04-20 04:44:08 +08:00
if (T.isOSVersionLT(3, 0))
TLI.setUnavailable(LibFunc::memset_pattern16);
} else {
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-19 05:50:34 +08:00
TLI.setUnavailable(LibFunc::memset_pattern16);
Target: Eliminate a use of getDarwinMajorNumber(). llvm-svn: 129803
2011-04-20 04:44:08 +08: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 21:17:51 +08: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 14:48:38 +08: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-05 00:28:20 +08: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 14:48:38 +08: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 09:27:36 +08:00
if (T.isMacOSX() && T.getArch() == Triple::x86 &&
!T.isMacOSXVersionLT(10, 7)) {
// x86-32 OSX has a scheme where fwrite and fputs (and some other functions
// we don't care about) have two versions; on recent OSX, the one we want
// has a $UNIX2003 suffix. The two implementations are identical except
// for the return value in some edge cases. However, we don't want to
// generate code that depends on the old symbols.
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 19:11:45 +08: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 21:17:51 +08: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 22:09:28 +08: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 22:20:22 +08: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 22:09:28 +08: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 07:05:54 +08: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 06:09:06 +08: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 07:05:54 +08: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-17 06:42:40 +08: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 07:05:54 +08: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-06 05:47:40 +08: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-05 04:27:23 +08: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 07:05:54 +08: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-06 05:47:40 +08: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 07:05:54 +08: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 07:28:56 +08:00
TLI.setUnavailable(LibFunc::acosh);
TLI.setUnavailable(LibFunc::acoshf);
TLI.setUnavailable(LibFunc::acoshl);
TLI.setUnavailable(LibFunc::asinh);
TLI.setUnavailable(LibFunc::asinhf);
TLI.setUnavailable(LibFunc::asinhl);
TLI.setUnavailable(LibFunc::atanh);
TLI.setUnavailable(LibFunc::atanhf);
TLI.setUnavailable(LibFunc::atanhl);
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 07:05:54 +08: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 07:28:56 +08: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 07:05:54 +08: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-17 06:42:40 +08: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 07:05:54 +08:00
TLI.setUnavailable(LibFunc::fmodf);
TLI.setUnavailable(LibFunc::logf);
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 11:11:06 +08: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-06 05:47:40 +08: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 23:36:42 +08: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-06 05:47:40 +08: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 12:00:51 +08: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-06 05:47:40 +08: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 23:36:42 +08: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-06 05:47:40 +08: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 23:36:42 +08: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-27 03:17:04 +08: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 10:40:19 +08:00
// exp10 and exp10f are not available on OS X until 10.9 and iOS until 7.0
// and their names are __exp10 and __exp10f. exp10l is not available on
// OS X or iOS.
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-27 03:17:04 +08: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:
TLI.setUnavailable(LibFunc::exp10l);
if (T.isOSVersionLT(7, 0)) {
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 10:40:19 +08:00
case Triple::Linux:
// exp10, exp10f, exp10l is available on Linux (GLIBC) but are extremely
// buggy prior to glibc version 2.18. Until this version is widely deployed
// or we have a reasonable detection strategy, we cannot use exp10 reliably
// on Linux.
//
// Fall through to disable all of them.
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-27 03:17:04 +08: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 23:36:42 +08:00
}
// ffsl is available on at least Darwin, Mac OS X, iOS, FreeBSD, and
// Linux (GLIBC):
// http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/ffsl.3.html
// http://svn.freebsd.org/base/user/eri/pf45/head/lib/libc/string/ffsl.c
// http://www.gnu.org/software/gnulib/manual/html_node/ffsl.html
switch (T.getOS()) {
case Triple::Darwin:
case Triple::MacOSX:
case Triple::IOS:
case Triple::FreeBSD:
case Triple::Linux:
break;
default:
TLI.setUnavailable(LibFunc::ffsl);
}
// ffsll is available on at least FreeBSD and Linux (GLIBC):
// http://svn.freebsd.org/base/user/eri/pf45/head/lib/libc/string/ffsll.c
// http://www.gnu.org/software/gnulib/manual/html_node/ffsll.html
switch (T.getOS()) {
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 07:05:54 +08: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-06 05:47:40 +08: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-30 04:23:14 +08: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-06 05:47:40 +08:00
TLI.setUnavailable(LibFunc::dunder_strdup);
TLI.setUnavailable(LibFunc::dunder_strtok_r);
TLI.setUnavailable(LibFunc::dunder_isoc99_scanf);
TLI.setUnavailable(LibFunc::dunder_isoc99_sscanf);
TLI.setUnavailable(LibFunc::under_IO_getc);
TLI.setUnavailable(LibFunc::under_IO_putc);
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);
}
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-19 05:50:34 +08:00
}
[PM] Rework how the TargetLibraryInfo pass integrates with the new pass manager to support the actual uses of it. =] When I ported instcombine to the new pass manager I discover that it didn't work because TLI wasn't available in the right places. This is a somewhat surprising and/or subtle aspect of the new pass manager design that came up before but I think is useful to be reminded of: While the new pass manager *allows* a function pass to query a module analysis, it requires that the module analysis is already run and cached prior to the function pass manager starting up, possibly with a 'require<foo>' style utility in the pass pipeline. This is an intentional hurdle because using a module analysis from a function pass *requires* that the module analysis is run prior to entering the function pass manager. Otherwise the other functions in the module could be in who-knows-what state, etc. A somewhat surprising consequence of this design decision (at least to me) is that you have to design a function pass that leverages a module analysis to do so as an optional feature. Even if that means your function pass does no work in the absence of the module analysis, you have to handle that possibility and remain conservatively correct. This is a natural consequence of things being able to invalidate the module analysis and us being unable to re-run it. And it's a generally good thing because it lets us reorder passes arbitrarily without breaking correctness, etc. This ends up causing problems in one case. What if we have a module analysis that is *definitionally* impossible to invalidate. In the places this might come up, the analysis is usually also definitionally trivial to run even while other transformation passes run on the module, regardless of the state of anything. And so, it follows that it is natural to have a hard requirement on such analyses from a function pass. It turns out, that TargetLibraryInfo is just such an analysis, and InstCombine has a hard requirement on it. The approach I've taken here is to produce an analysis that models this flexibility by making it both a module and a function analysis. This exposes the fact that it is in fact safe to compute at any point. We can even make it a valid CGSCC analysis at some point if that is useful. However, we don't want to have a copy of the actual target library info state for each function! This state is specific to the triple. The somewhat direct and blunt approach here is to turn TLI into a pimpl, with the state and mutators in the implementation class and the query routines primarily in the wrapper. Then the analysis can lazily construct and cache the implementations, keyed on the triple, and on-demand produce wrappers of them for each function. One minor annoyance is that we will end up with a wrapper for each function in the module. While this is a bit wasteful (one pointer per function) it seems tolerable. And it has the advantage of ensuring that we pay the absolute minimum synchronization cost to access this information should we end up with a nice parallel function pass manager in the future. We could look into trying to mark when analysis results are especially cheap to recompute and more eagerly GC-ing the cached results, or we could look at supporting a variant of analyses whose results are specifically *not* cached and expected to just be used and discarded by the consumer. Either way, these seem like incremental enhancements that should happen when we start profiling the memory and CPU usage of the new pass manager and not before. The other minor annoyance is that if we end up using the TLI in both a module pass and a function pass, those will be produced by two separate analyses, and thus will point to separate copies of the implementation state. While a minor issue, I dislike this and would like to find a way to cleanly allow a single analysis instance to be used across multiple IR unit managers. But I don't have a good solution to this today, and I don't want to hold up all of the work waiting to come up with one. This too seems like a reasonable thing to incrementally improve later. llvm-svn: 226981
2015-01-24 10:06:09 +08:00
TargetLibraryInfoImpl::TargetLibraryInfoImpl() {
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-19 05:50:34 +08: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 12:06:22 +08: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-19 05:50:34 +08:00
}
[PM] Rework how the TargetLibraryInfo pass integrates with the new pass manager to support the actual uses of it. =] When I ported instcombine to the new pass manager I discover that it didn't work because TLI wasn't available in the right places. This is a somewhat surprising and/or subtle aspect of the new pass manager design that came up before but I think is useful to be reminded of: While the new pass manager *allows* a function pass to query a module analysis, it requires that the module analysis is already run and cached prior to the function pass manager starting up, possibly with a 'require<foo>' style utility in the pass pipeline. This is an intentional hurdle because using a module analysis from a function pass *requires* that the module analysis is run prior to entering the function pass manager. Otherwise the other functions in the module could be in who-knows-what state, etc. A somewhat surprising consequence of this design decision (at least to me) is that you have to design a function pass that leverages a module analysis to do so as an optional feature. Even if that means your function pass does no work in the absence of the module analysis, you have to handle that possibility and remain conservatively correct. This is a natural consequence of things being able to invalidate the module analysis and us being unable to re-run it. And it's a generally good thing because it lets us reorder passes arbitrarily without breaking correctness, etc. This ends up causing problems in one case. What if we have a module analysis that is *definitionally* impossible to invalidate. In the places this might come up, the analysis is usually also definitionally trivial to run even while other transformation passes run on the module, regardless of the state of anything. And so, it follows that it is natural to have a hard requirement on such analyses from a function pass. It turns out, that TargetLibraryInfo is just such an analysis, and InstCombine has a hard requirement on it. The approach I've taken here is to produce an analysis that models this flexibility by making it both a module and a function analysis. This exposes the fact that it is in fact safe to compute at any point. We can even make it a valid CGSCC analysis at some point if that is useful. However, we don't want to have a copy of the actual target library info state for each function! This state is specific to the triple. The somewhat direct and blunt approach here is to turn TLI into a pimpl, with the state and mutators in the implementation class and the query routines primarily in the wrapper. Then the analysis can lazily construct and cache the implementations, keyed on the triple, and on-demand produce wrappers of them for each function. One minor annoyance is that we will end up with a wrapper for each function in the module. While this is a bit wasteful (one pointer per function) it seems tolerable. And it has the advantage of ensuring that we pay the absolute minimum synchronization cost to access this information should we end up with a nice parallel function pass manager in the future. We could look into trying to mark when analysis results are especially cheap to recompute and more eagerly GC-ing the cached results, or we could look at supporting a variant of analyses whose results are specifically *not* cached and expected to just be used and discarded by the consumer. Either way, these seem like incremental enhancements that should happen when we start profiling the memory and CPU usage of the new pass manager and not before. The other minor annoyance is that if we end up using the TLI in both a module pass and a function pass, those will be produced by two separate analyses, and thus will point to separate copies of the implementation state. While a minor issue, I dislike this and would like to find a way to cleanly allow a single analysis instance to be used across multiple IR unit managers. But I don't have a good solution to this today, and I don't want to hold up all of the work waiting to come up with one. This too seems like a reasonable thing to incrementally improve later. llvm-svn: 226981
2015-01-24 10:06:09 +08:00
TargetLibraryInfoImpl::TargetLibraryInfoImpl(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-19 05:50:34 +08: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 18:41:28 +08: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 12:06:22 +08: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-19 05:50:34 +08:00
}
add a way to disable all builtins, wire it up to opt's -disable-simplifylibcalls flag. llvm-svn: 125978
2011-02-19 06:34:03 +08:00
[PM] Rework how the TargetLibraryInfo pass integrates with the new pass manager to support the actual uses of it. =] When I ported instcombine to the new pass manager I discover that it didn't work because TLI wasn't available in the right places. This is a somewhat surprising and/or subtle aspect of the new pass manager design that came up before but I think is useful to be reminded of: While the new pass manager *allows* a function pass to query a module analysis, it requires that the module analysis is already run and cached prior to the function pass manager starting up, possibly with a 'require<foo>' style utility in the pass pipeline. This is an intentional hurdle because using a module analysis from a function pass *requires* that the module analysis is run prior to entering the function pass manager. Otherwise the other functions in the module could be in who-knows-what state, etc. A somewhat surprising consequence of this design decision (at least to me) is that you have to design a function pass that leverages a module analysis to do so as an optional feature. Even if that means your function pass does no work in the absence of the module analysis, you have to handle that possibility and remain conservatively correct. This is a natural consequence of things being able to invalidate the module analysis and us being unable to re-run it. And it's a generally good thing because it lets us reorder passes arbitrarily without breaking correctness, etc. This ends up causing problems in one case. What if we have a module analysis that is *definitionally* impossible to invalidate. In the places this might come up, the analysis is usually also definitionally trivial to run even while other transformation passes run on the module, regardless of the state of anything. And so, it follows that it is natural to have a hard requirement on such analyses from a function pass. It turns out, that TargetLibraryInfo is just such an analysis, and InstCombine has a hard requirement on it. The approach I've taken here is to produce an analysis that models this flexibility by making it both a module and a function analysis. This exposes the fact that it is in fact safe to compute at any point. We can even make it a valid CGSCC analysis at some point if that is useful. However, we don't want to have a copy of the actual target library info state for each function! This state is specific to the triple. The somewhat direct and blunt approach here is to turn TLI into a pimpl, with the state and mutators in the implementation class and the query routines primarily in the wrapper. Then the analysis can lazily construct and cache the implementations, keyed on the triple, and on-demand produce wrappers of them for each function. One minor annoyance is that we will end up with a wrapper for each function in the module. While this is a bit wasteful (one pointer per function) it seems tolerable. And it has the advantage of ensuring that we pay the absolute minimum synchronization cost to access this information should we end up with a nice parallel function pass manager in the future. We could look into trying to mark when analysis results are especially cheap to recompute and more eagerly GC-ing the cached results, or we could look at supporting a variant of analyses whose results are specifically *not* cached and expected to just be used and discarded by the consumer. Either way, these seem like incremental enhancements that should happen when we start profiling the memory and CPU usage of the new pass manager and not before. The other minor annoyance is that if we end up using the TLI in both a module pass and a function pass, those will be produced by two separate analyses, and thus will point to separate copies of the implementation state. While a minor issue, I dislike this and would like to find a way to cleanly allow a single analysis instance to be used across multiple IR unit managers. But I don't have a good solution to this today, and I don't want to hold up all of the work waiting to come up with one. This too seems like a reasonable thing to incrementally improve later. llvm-svn: 226981
2015-01-24 10:06:09 +08:00
TargetLibraryInfoImpl::TargetLibraryInfoImpl(const TargetLibraryInfoImpl &TLI)
[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 19:39:46 +08:00
: CustomNames(TLI.CustomNames) {
add a copy ctor to TargetLibraryInfo. llvm-svn: 131806
2011-05-22 04:09:13 +08:00
memcpy(AvailableArray, TLI.AvailableArray, sizeof(AvailableArray));
[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 19:39:46 +08:00
}
[PM] Rework how the TargetLibraryInfo pass integrates with the new pass manager to support the actual uses of it. =] When I ported instcombine to the new pass manager I discover that it didn't work because TLI wasn't available in the right places. This is a somewhat surprising and/or subtle aspect of the new pass manager design that came up before but I think is useful to be reminded of: While the new pass manager *allows* a function pass to query a module analysis, it requires that the module analysis is already run and cached prior to the function pass manager starting up, possibly with a 'require<foo>' style utility in the pass pipeline. This is an intentional hurdle because using a module analysis from a function pass *requires* that the module analysis is run prior to entering the function pass manager. Otherwise the other functions in the module could be in who-knows-what state, etc. A somewhat surprising consequence of this design decision (at least to me) is that you have to design a function pass that leverages a module analysis to do so as an optional feature. Even if that means your function pass does no work in the absence of the module analysis, you have to handle that possibility and remain conservatively correct. This is a natural consequence of things being able to invalidate the module analysis and us being unable to re-run it. And it's a generally good thing because it lets us reorder passes arbitrarily without breaking correctness, etc. This ends up causing problems in one case. What if we have a module analysis that is *definitionally* impossible to invalidate. In the places this might come up, the analysis is usually also definitionally trivial to run even while other transformation passes run on the module, regardless of the state of anything. And so, it follows that it is natural to have a hard requirement on such analyses from a function pass. It turns out, that TargetLibraryInfo is just such an analysis, and InstCombine has a hard requirement on it. The approach I've taken here is to produce an analysis that models this flexibility by making it both a module and a function analysis. This exposes the fact that it is in fact safe to compute at any point. We can even make it a valid CGSCC analysis at some point if that is useful. However, we don't want to have a copy of the actual target library info state for each function! This state is specific to the triple. The somewhat direct and blunt approach here is to turn TLI into a pimpl, with the state and mutators in the implementation class and the query routines primarily in the wrapper. Then the analysis can lazily construct and cache the implementations, keyed on the triple, and on-demand produce wrappers of them for each function. One minor annoyance is that we will end up with a wrapper for each function in the module. While this is a bit wasteful (one pointer per function) it seems tolerable. And it has the advantage of ensuring that we pay the absolute minimum synchronization cost to access this information should we end up with a nice parallel function pass manager in the future. We could look into trying to mark when analysis results are especially cheap to recompute and more eagerly GC-ing the cached results, or we could look at supporting a variant of analyses whose results are specifically *not* cached and expected to just be used and discarded by the consumer. Either way, these seem like incremental enhancements that should happen when we start profiling the memory and CPU usage of the new pass manager and not before. The other minor annoyance is that if we end up using the TLI in both a module pass and a function pass, those will be produced by two separate analyses, and thus will point to separate copies of the implementation state. While a minor issue, I dislike this and would like to find a way to cleanly allow a single analysis instance to be used across multiple IR unit managers. But I don't have a good solution to this today, and I don't want to hold up all of the work waiting to come up with one. This too seems like a reasonable thing to incrementally improve later. llvm-svn: 226981
2015-01-24 10:06:09 +08:00
TargetLibraryInfoImpl::TargetLibraryInfoImpl(TargetLibraryInfoImpl &&TLI)
[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 19:39:46 +08:00
: CustomNames(std::move(TLI.CustomNames)) {
std::move(std::begin(TLI.AvailableArray), std::end(TLI.AvailableArray),
AvailableArray);
}
[PM] Rework how the TargetLibraryInfo pass integrates with the new pass manager to support the actual uses of it. =] When I ported instcombine to the new pass manager I discover that it didn't work because TLI wasn't available in the right places. This is a somewhat surprising and/or subtle aspect of the new pass manager design that came up before but I think is useful to be reminded of: While the new pass manager *allows* a function pass to query a module analysis, it requires that the module analysis is already run and cached prior to the function pass manager starting up, possibly with a 'require<foo>' style utility in the pass pipeline. This is an intentional hurdle because using a module analysis from a function pass *requires* that the module analysis is run prior to entering the function pass manager. Otherwise the other functions in the module could be in who-knows-what state, etc. A somewhat surprising consequence of this design decision (at least to me) is that you have to design a function pass that leverages a module analysis to do so as an optional feature. Even if that means your function pass does no work in the absence of the module analysis, you have to handle that possibility and remain conservatively correct. This is a natural consequence of things being able to invalidate the module analysis and us being unable to re-run it. And it's a generally good thing because it lets us reorder passes arbitrarily without breaking correctness, etc. This ends up causing problems in one case. What if we have a module analysis that is *definitionally* impossible to invalidate. In the places this might come up, the analysis is usually also definitionally trivial to run even while other transformation passes run on the module, regardless of the state of anything. And so, it follows that it is natural to have a hard requirement on such analyses from a function pass. It turns out, that TargetLibraryInfo is just such an analysis, and InstCombine has a hard requirement on it. The approach I've taken here is to produce an analysis that models this flexibility by making it both a module and a function analysis. This exposes the fact that it is in fact safe to compute at any point. We can even make it a valid CGSCC analysis at some point if that is useful. However, we don't want to have a copy of the actual target library info state for each function! This state is specific to the triple. The somewhat direct and blunt approach here is to turn TLI into a pimpl, with the state and mutators in the implementation class and the query routines primarily in the wrapper. Then the analysis can lazily construct and cache the implementations, keyed on the triple, and on-demand produce wrappers of them for each function. One minor annoyance is that we will end up with a wrapper for each function in the module. While this is a bit wasteful (one pointer per function) it seems tolerable. And it has the advantage of ensuring that we pay the absolute minimum synchronization cost to access this information should we end up with a nice parallel function pass manager in the future. We could look into trying to mark when analysis results are especially cheap to recompute and more eagerly GC-ing the cached results, or we could look at supporting a variant of analyses whose results are specifically *not* cached and expected to just be used and discarded by the consumer. Either way, these seem like incremental enhancements that should happen when we start profiling the memory and CPU usage of the new pass manager and not before. The other minor annoyance is that if we end up using the TLI in both a module pass and a function pass, those will be produced by two separate analyses, and thus will point to separate copies of the implementation state. While a minor issue, I dislike this and would like to find a way to cleanly allow a single analysis instance to be used across multiple IR unit managers. But I don't have a good solution to this today, and I don't want to hold up all of the work waiting to come up with one. This too seems like a reasonable thing to incrementally improve later. llvm-svn: 226981
2015-01-24 10:06:09 +08:00
TargetLibraryInfoImpl &TargetLibraryInfoImpl::operator=(const TargetLibraryInfoImpl &TLI) {
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 09:27:36 +08:00
CustomNames = TLI.CustomNames;
[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 19:39:46 +08:00
memcpy(AvailableArray, TLI.AvailableArray, sizeof(AvailableArray));
return *this;
}
[PM] Rework how the TargetLibraryInfo pass integrates with the new pass manager to support the actual uses of it. =] When I ported instcombine to the new pass manager I discover that it didn't work because TLI wasn't available in the right places. This is a somewhat surprising and/or subtle aspect of the new pass manager design that came up before but I think is useful to be reminded of: While the new pass manager *allows* a function pass to query a module analysis, it requires that the module analysis is already run and cached prior to the function pass manager starting up, possibly with a 'require<foo>' style utility in the pass pipeline. This is an intentional hurdle because using a module analysis from a function pass *requires* that the module analysis is run prior to entering the function pass manager. Otherwise the other functions in the module could be in who-knows-what state, etc. A somewhat surprising consequence of this design decision (at least to me) is that you have to design a function pass that leverages a module analysis to do so as an optional feature. Even if that means your function pass does no work in the absence of the module analysis, you have to handle that possibility and remain conservatively correct. This is a natural consequence of things being able to invalidate the module analysis and us being unable to re-run it. And it's a generally good thing because it lets us reorder passes arbitrarily without breaking correctness, etc. This ends up causing problems in one case. What if we have a module analysis that is *definitionally* impossible to invalidate. In the places this might come up, the analysis is usually also definitionally trivial to run even while other transformation passes run on the module, regardless of the state of anything. And so, it follows that it is natural to have a hard requirement on such analyses from a function pass. It turns out, that TargetLibraryInfo is just such an analysis, and InstCombine has a hard requirement on it. The approach I've taken here is to produce an analysis that models this flexibility by making it both a module and a function analysis. This exposes the fact that it is in fact safe to compute at any point. We can even make it a valid CGSCC analysis at some point if that is useful. However, we don't want to have a copy of the actual target library info state for each function! This state is specific to the triple. The somewhat direct and blunt approach here is to turn TLI into a pimpl, with the state and mutators in the implementation class and the query routines primarily in the wrapper. Then the analysis can lazily construct and cache the implementations, keyed on the triple, and on-demand produce wrappers of them for each function. One minor annoyance is that we will end up with a wrapper for each function in the module. While this is a bit wasteful (one pointer per function) it seems tolerable. And it has the advantage of ensuring that we pay the absolute minimum synchronization cost to access this information should we end up with a nice parallel function pass manager in the future. We could look into trying to mark when analysis results are especially cheap to recompute and more eagerly GC-ing the cached results, or we could look at supporting a variant of analyses whose results are specifically *not* cached and expected to just be used and discarded by the consumer. Either way, these seem like incremental enhancements that should happen when we start profiling the memory and CPU usage of the new pass manager and not before. The other minor annoyance is that if we end up using the TLI in both a module pass and a function pass, those will be produced by two separate analyses, and thus will point to separate copies of the implementation state. While a minor issue, I dislike this and would like to find a way to cleanly allow a single analysis instance to be used across multiple IR unit managers. But I don't have a good solution to this today, and I don't want to hold up all of the work waiting to come up with one. This too seems like a reasonable thing to incrementally improve later. llvm-svn: 226981
2015-01-24 10:06:09 +08:00
TargetLibraryInfoImpl &TargetLibraryInfoImpl::operator=(TargetLibraryInfoImpl &&TLI) {
[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 19:39:46 +08:00
CustomNames = std::move(TLI.CustomNames);
std::move(std::begin(TLI.AvailableArray), std::end(TLI.AvailableArray),
AvailableArray);
return *this;
add a copy ctor to TargetLibraryInfo. llvm-svn: 131806
2011-05-22 04:09:13 +08:00
}
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 21:48:23 +08:00
namespace {
struct StringComparator {
/// Compare two strings and return true if LHS is lexicographically less than
/// RHS. Requires that RHS doesn't contain any zero bytes.
bool operator()(const char *LHS, StringRef RHS) const {
// Compare prefixes with strncmp. If prefixes match we know that LHS is
// greater or equal to RHS as RHS can't contain any '\0'.
return std::strncmp(LHS, RHS.data(), RHS.size()) < 0;
}
// Provided for compatibility with MSVC's debug mode.
bool operator()(StringRef LHS, const char *RHS) const { return LHS < RHS; }
bool operator()(StringRef LHS, StringRef RHS) const { return LHS < RHS; }
Add one more overload to make VS2008's debug mody happy. sigh. llvm-svn: 176946
2013-03-13 21:50:47 +08:00
bool operator()(const char *LHS, const char *RHS) const {
return std::strcmp(LHS, RHS) < 0;
}
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 21:48:23 +08:00
};
}
[PM] Rework how the TargetLibraryInfo pass integrates with the new pass manager to support the actual uses of it. =] When I ported instcombine to the new pass manager I discover that it didn't work because TLI wasn't available in the right places. This is a somewhat surprising and/or subtle aspect of the new pass manager design that came up before but I think is useful to be reminded of: While the new pass manager *allows* a function pass to query a module analysis, it requires that the module analysis is already run and cached prior to the function pass manager starting up, possibly with a 'require<foo>' style utility in the pass pipeline. This is an intentional hurdle because using a module analysis from a function pass *requires* that the module analysis is run prior to entering the function pass manager. Otherwise the other functions in the module could be in who-knows-what state, etc. A somewhat surprising consequence of this design decision (at least to me) is that you have to design a function pass that leverages a module analysis to do so as an optional feature. Even if that means your function pass does no work in the absence of the module analysis, you have to handle that possibility and remain conservatively correct. This is a natural consequence of things being able to invalidate the module analysis and us being unable to re-run it. And it's a generally good thing because it lets us reorder passes arbitrarily without breaking correctness, etc. This ends up causing problems in one case. What if we have a module analysis that is *definitionally* impossible to invalidate. In the places this might come up, the analysis is usually also definitionally trivial to run even while other transformation passes run on the module, regardless of the state of anything. And so, it follows that it is natural to have a hard requirement on such analyses from a function pass. It turns out, that TargetLibraryInfo is just such an analysis, and InstCombine has a hard requirement on it. The approach I've taken here is to produce an analysis that models this flexibility by making it both a module and a function analysis. This exposes the fact that it is in fact safe to compute at any point. We can even make it a valid CGSCC analysis at some point if that is useful. However, we don't want to have a copy of the actual target library info state for each function! This state is specific to the triple. The somewhat direct and blunt approach here is to turn TLI into a pimpl, with the state and mutators in the implementation class and the query routines primarily in the wrapper. Then the analysis can lazily construct and cache the implementations, keyed on the triple, and on-demand produce wrappers of them for each function. One minor annoyance is that we will end up with a wrapper for each function in the module. While this is a bit wasteful (one pointer per function) it seems tolerable. And it has the advantage of ensuring that we pay the absolute minimum synchronization cost to access this information should we end up with a nice parallel function pass manager in the future. We could look into trying to mark when analysis results are especially cheap to recompute and more eagerly GC-ing the cached results, or we could look at supporting a variant of analyses whose results are specifically *not* cached and expected to just be used and discarded by the consumer. Either way, these seem like incremental enhancements that should happen when we start profiling the memory and CPU usage of the new pass manager and not before. The other minor annoyance is that if we end up using the TLI in both a module pass and a function pass, those will be produced by two separate analyses, and thus will point to separate copies of the implementation state. While a minor issue, I dislike this and would like to find a way to cleanly allow a single analysis instance to be used across multiple IR unit managers. But I don't have a good solution to this today, and I don't want to hold up all of the work waiting to come up with one. This too seems like a reasonable thing to incrementally improve later. llvm-svn: 226981
2015-01-24 10:06:09 +08:00
bool TargetLibraryInfoImpl::getLibFunc(StringRef funcName,
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 12:06:22 +08:00
LibFunc::Func &F) const {
const char **Start = &StandardNames[0];
const char **End = &StandardNames[LibFunc::NumLibFuncs];
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 21:48:23 +08:00
// Filter out empty names and names containing null bytes, those can't be in
// our table.
if (funcName.empty() || funcName.find('\0') != StringRef::npos)
return false;
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-06 05:47:40 +08:00
// Check for \01 prefix that is used to mangle __asm declarations and
// strip it if present.
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 21:48:23 +08:00
if (funcName.front() == '\01')
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-06 05:47:40 +08:00
funcName = funcName.substr(1);
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 21:48:23 +08:00
const char **I = std::lower_bound(Start, End, funcName, StringComparator());
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 12:06:22 +08: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-22 04:09:13 +08:00
[PM] Rework how the TargetLibraryInfo pass integrates with the new pass manager to support the actual uses of it. =] When I ported instcombine to the new pass manager I discover that it didn't work because TLI wasn't available in the right places. This is a somewhat surprising and/or subtle aspect of the new pass manager design that came up before but I think is useful to be reminded of: While the new pass manager *allows* a function pass to query a module analysis, it requires that the module analysis is already run and cached prior to the function pass manager starting up, possibly with a 'require<foo>' style utility in the pass pipeline. This is an intentional hurdle because using a module analysis from a function pass *requires* that the module analysis is run prior to entering the function pass manager. Otherwise the other functions in the module could be in who-knows-what state, etc. A somewhat surprising consequence of this design decision (at least to me) is that you have to design a function pass that leverages a module analysis to do so as an optional feature. Even if that means your function pass does no work in the absence of the module analysis, you have to handle that possibility and remain conservatively correct. This is a natural consequence of things being able to invalidate the module analysis and us being unable to re-run it. And it's a generally good thing because it lets us reorder passes arbitrarily without breaking correctness, etc. This ends up causing problems in one case. What if we have a module analysis that is *definitionally* impossible to invalidate. In the places this might come up, the analysis is usually also definitionally trivial to run even while other transformation passes run on the module, regardless of the state of anything. And so, it follows that it is natural to have a hard requirement on such analyses from a function pass. It turns out, that TargetLibraryInfo is just such an analysis, and InstCombine has a hard requirement on it. The approach I've taken here is to produce an analysis that models this flexibility by making it both a module and a function analysis. This exposes the fact that it is in fact safe to compute at any point. We can even make it a valid CGSCC analysis at some point if that is useful. However, we don't want to have a copy of the actual target library info state for each function! This state is specific to the triple. The somewhat direct and blunt approach here is to turn TLI into a pimpl, with the state and mutators in the implementation class and the query routines primarily in the wrapper. Then the analysis can lazily construct and cache the implementations, keyed on the triple, and on-demand produce wrappers of them for each function. One minor annoyance is that we will end up with a wrapper for each function in the module. While this is a bit wasteful (one pointer per function) it seems tolerable. And it has the advantage of ensuring that we pay the absolute minimum synchronization cost to access this information should we end up with a nice parallel function pass manager in the future. We could look into trying to mark when analysis results are especially cheap to recompute and more eagerly GC-ing the cached results, or we could look at supporting a variant of analyses whose results are specifically *not* cached and expected to just be used and discarded by the consumer. Either way, these seem like incremental enhancements that should happen when we start profiling the memory and CPU usage of the new pass manager and not before. The other minor annoyance is that if we end up using the TLI in both a module pass and a function pass, those will be produced by two separate analyses, and thus will point to separate copies of the implementation state. While a minor issue, I dislike this and would like to find a way to cleanly allow a single analysis instance to be used across multiple IR unit managers. But I don't have a good solution to this today, and I don't want to hold up all of the work waiting to come up with one. This too seems like a reasonable thing to incrementally improve later. llvm-svn: 226981
2015-01-24 10:06:09 +08:00
void TargetLibraryInfoImpl::disableAllFunctions() {
add a way to disable all builtins, wire it up to opt's -disable-simplifylibcalls flag. llvm-svn: 125978
2011-02-19 06:34:03 +08: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 18:41:28 +08:00
[PM] Rework how the TargetLibraryInfo pass integrates with the new pass manager to support the actual uses of it. =] When I ported instcombine to the new pass manager I discover that it didn't work because TLI wasn't available in the right places. This is a somewhat surprising and/or subtle aspect of the new pass manager design that came up before but I think is useful to be reminded of: While the new pass manager *allows* a function pass to query a module analysis, it requires that the module analysis is already run and cached prior to the function pass manager starting up, possibly with a 'require<foo>' style utility in the pass pipeline. This is an intentional hurdle because using a module analysis from a function pass *requires* that the module analysis is run prior to entering the function pass manager. Otherwise the other functions in the module could be in who-knows-what state, etc. A somewhat surprising consequence of this design decision (at least to me) is that you have to design a function pass that leverages a module analysis to do so as an optional feature. Even if that means your function pass does no work in the absence of the module analysis, you have to handle that possibility and remain conservatively correct. This is a natural consequence of things being able to invalidate the module analysis and us being unable to re-run it. And it's a generally good thing because it lets us reorder passes arbitrarily without breaking correctness, etc. This ends up causing problems in one case. What if we have a module analysis that is *definitionally* impossible to invalidate. In the places this might come up, the analysis is usually also definitionally trivial to run even while other transformation passes run on the module, regardless of the state of anything. And so, it follows that it is natural to have a hard requirement on such analyses from a function pass. It turns out, that TargetLibraryInfo is just such an analysis, and InstCombine has a hard requirement on it. The approach I've taken here is to produce an analysis that models this flexibility by making it both a module and a function analysis. This exposes the fact that it is in fact safe to compute at any point. We can even make it a valid CGSCC analysis at some point if that is useful. However, we don't want to have a copy of the actual target library info state for each function! This state is specific to the triple. The somewhat direct and blunt approach here is to turn TLI into a pimpl, with the state and mutators in the implementation class and the query routines primarily in the wrapper. Then the analysis can lazily construct and cache the implementations, keyed on the triple, and on-demand produce wrappers of them for each function. One minor annoyance is that we will end up with a wrapper for each function in the module. While this is a bit wasteful (one pointer per function) it seems tolerable. And it has the advantage of ensuring that we pay the absolute minimum synchronization cost to access this information should we end up with a nice parallel function pass manager in the future. We could look into trying to mark when analysis results are especially cheap to recompute and more eagerly GC-ing the cached results, or we could look at supporting a variant of analyses whose results are specifically *not* cached and expected to just be used and discarded by the consumer. Either way, these seem like incremental enhancements that should happen when we start profiling the memory and CPU usage of the new pass manager and not before. The other minor annoyance is that if we end up using the TLI in both a module pass and a function pass, those will be produced by two separate analyses, and thus will point to separate copies of the implementation state. While a minor issue, I dislike this and would like to find a way to cleanly allow a single analysis instance to be used across multiple IR unit managers. But I don't have a good solution to this today, and I don't want to hold up all of the work waiting to come up with one. This too seems like a reasonable thing to incrementally improve later. llvm-svn: 226981
2015-01-24 10:06:09 +08:00
TargetLibraryInfo TargetLibraryAnalysis::run(Module &M) {
if (PresetInfoImpl)
return TargetLibraryInfo(*PresetInfoImpl);
return TargetLibraryInfo(lookupInfoImpl(Triple(M.getTargetTriple())));
}
TargetLibraryInfo TargetLibraryAnalysis::run(Function &F) {
if (PresetInfoImpl)
return TargetLibraryInfo(*PresetInfoImpl);
return TargetLibraryInfo(
lookupInfoImpl(Triple(F.getParent()->getTargetTriple())));
}
TargetLibraryInfoImpl &TargetLibraryAnalysis::lookupInfoImpl(Triple T) {
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 18:41:28 +08:00
TargetLibraryInfoWrapperPass::TargetLibraryInfoWrapperPass()
[PM] Rework how the TargetLibraryInfo pass integrates with the new pass manager to support the actual uses of it. =] When I ported instcombine to the new pass manager I discover that it didn't work because TLI wasn't available in the right places. This is a somewhat surprising and/or subtle aspect of the new pass manager design that came up before but I think is useful to be reminded of: While the new pass manager *allows* a function pass to query a module analysis, it requires that the module analysis is already run and cached prior to the function pass manager starting up, possibly with a 'require<foo>' style utility in the pass pipeline. This is an intentional hurdle because using a module analysis from a function pass *requires* that the module analysis is run prior to entering the function pass manager. Otherwise the other functions in the module could be in who-knows-what state, etc. A somewhat surprising consequence of this design decision (at least to me) is that you have to design a function pass that leverages a module analysis to do so as an optional feature. Even if that means your function pass does no work in the absence of the module analysis, you have to handle that possibility and remain conservatively correct. This is a natural consequence of things being able to invalidate the module analysis and us being unable to re-run it. And it's a generally good thing because it lets us reorder passes arbitrarily without breaking correctness, etc. This ends up causing problems in one case. What if we have a module analysis that is *definitionally* impossible to invalidate. In the places this might come up, the analysis is usually also definitionally trivial to run even while other transformation passes run on the module, regardless of the state of anything. And so, it follows that it is natural to have a hard requirement on such analyses from a function pass. It turns out, that TargetLibraryInfo is just such an analysis, and InstCombine has a hard requirement on it. The approach I've taken here is to produce an analysis that models this flexibility by making it both a module and a function analysis. This exposes the fact that it is in fact safe to compute at any point. We can even make it a valid CGSCC analysis at some point if that is useful. However, we don't want to have a copy of the actual target library info state for each function! This state is specific to the triple. The somewhat direct and blunt approach here is to turn TLI into a pimpl, with the state and mutators in the implementation class and the query routines primarily in the wrapper. Then the analysis can lazily construct and cache the implementations, keyed on the triple, and on-demand produce wrappers of them for each function. One minor annoyance is that we will end up with a wrapper for each function in the module. While this is a bit wasteful (one pointer per function) it seems tolerable. And it has the advantage of ensuring that we pay the absolute minimum synchronization cost to access this information should we end up with a nice parallel function pass manager in the future. We could look into trying to mark when analysis results are especially cheap to recompute and more eagerly GC-ing the cached results, or we could look at supporting a variant of analyses whose results are specifically *not* cached and expected to just be used and discarded by the consumer. Either way, these seem like incremental enhancements that should happen when we start profiling the memory and CPU usage of the new pass manager and not before. The other minor annoyance is that if we end up using the TLI in both a module pass and a function pass, those will be produced by two separate analyses, and thus will point to separate copies of the implementation state. While a minor issue, I dislike this and would like to find a way to cleanly allow a single analysis instance to be used across multiple IR unit managers. But I don't have a good solution to this today, and I don't want to hold up all of the work waiting to come up with one. This too seems like a reasonable thing to incrementally improve later. llvm-svn: 226981
2015-01-24 10:06:09 +08:00
: ImmutablePass(ID), TLIImpl(), TLI(TLIImpl) {
[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 18:41:28 +08:00
initializeTargetLibraryInfoWrapperPassPass(*PassRegistry::getPassRegistry());
}
TargetLibraryInfoWrapperPass::TargetLibraryInfoWrapperPass(const Triple &T)
[PM] Rework how the TargetLibraryInfo pass integrates with the new pass manager to support the actual uses of it. =] When I ported instcombine to the new pass manager I discover that it didn't work because TLI wasn't available in the right places. This is a somewhat surprising and/or subtle aspect of the new pass manager design that came up before but I think is useful to be reminded of: While the new pass manager *allows* a function pass to query a module analysis, it requires that the module analysis is already run and cached prior to the function pass manager starting up, possibly with a 'require<foo>' style utility in the pass pipeline. This is an intentional hurdle because using a module analysis from a function pass *requires* that the module analysis is run prior to entering the function pass manager. Otherwise the other functions in the module could be in who-knows-what state, etc. A somewhat surprising consequence of this design decision (at least to me) is that you have to design a function pass that leverages a module analysis to do so as an optional feature. Even if that means your function pass does no work in the absence of the module analysis, you have to handle that possibility and remain conservatively correct. This is a natural consequence of things being able to invalidate the module analysis and us being unable to re-run it. And it's a generally good thing because it lets us reorder passes arbitrarily without breaking correctness, etc. This ends up causing problems in one case. What if we have a module analysis that is *definitionally* impossible to invalidate. In the places this might come up, the analysis is usually also definitionally trivial to run even while other transformation passes run on the module, regardless of the state of anything. And so, it follows that it is natural to have a hard requirement on such analyses from a function pass. It turns out, that TargetLibraryInfo is just such an analysis, and InstCombine has a hard requirement on it. The approach I've taken here is to produce an analysis that models this flexibility by making it both a module and a function analysis. This exposes the fact that it is in fact safe to compute at any point. We can even make it a valid CGSCC analysis at some point if that is useful. However, we don't want to have a copy of the actual target library info state for each function! This state is specific to the triple. The somewhat direct and blunt approach here is to turn TLI into a pimpl, with the state and mutators in the implementation class and the query routines primarily in the wrapper. Then the analysis can lazily construct and cache the implementations, keyed on the triple, and on-demand produce wrappers of them for each function. One minor annoyance is that we will end up with a wrapper for each function in the module. While this is a bit wasteful (one pointer per function) it seems tolerable. And it has the advantage of ensuring that we pay the absolute minimum synchronization cost to access this information should we end up with a nice parallel function pass manager in the future. We could look into trying to mark when analysis results are especially cheap to recompute and more eagerly GC-ing the cached results, or we could look at supporting a variant of analyses whose results are specifically *not* cached and expected to just be used and discarded by the consumer. Either way, these seem like incremental enhancements that should happen when we start profiling the memory and CPU usage of the new pass manager and not before. The other minor annoyance is that if we end up using the TLI in both a module pass and a function pass, those will be produced by two separate analyses, and thus will point to separate copies of the implementation state. While a minor issue, I dislike this and would like to find a way to cleanly allow a single analysis instance to be used across multiple IR unit managers. But I don't have a good solution to this today, and I don't want to hold up all of the work waiting to come up with one. This too seems like a reasonable thing to incrementally improve later. llvm-svn: 226981
2015-01-24 10:06:09 +08:00
: ImmutablePass(ID), TLIImpl(T), TLI(TLIImpl) {
[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 18:41:28 +08:00
initializeTargetLibraryInfoWrapperPassPass(*PassRegistry::getPassRegistry());
}
TargetLibraryInfoWrapperPass::TargetLibraryInfoWrapperPass(
[PM] Rework how the TargetLibraryInfo pass integrates with the new pass manager to support the actual uses of it. =] When I ported instcombine to the new pass manager I discover that it didn't work because TLI wasn't available in the right places. This is a somewhat surprising and/or subtle aspect of the new pass manager design that came up before but I think is useful to be reminded of: While the new pass manager *allows* a function pass to query a module analysis, it requires that the module analysis is already run and cached prior to the function pass manager starting up, possibly with a 'require<foo>' style utility in the pass pipeline. This is an intentional hurdle because using a module analysis from a function pass *requires* that the module analysis is run prior to entering the function pass manager. Otherwise the other functions in the module could be in who-knows-what state, etc. A somewhat surprising consequence of this design decision (at least to me) is that you have to design a function pass that leverages a module analysis to do so as an optional feature. Even if that means your function pass does no work in the absence of the module analysis, you have to handle that possibility and remain conservatively correct. This is a natural consequence of things being able to invalidate the module analysis and us being unable to re-run it. And it's a generally good thing because it lets us reorder passes arbitrarily without breaking correctness, etc. This ends up causing problems in one case. What if we have a module analysis that is *definitionally* impossible to invalidate. In the places this might come up, the analysis is usually also definitionally trivial to run even while other transformation passes run on the module, regardless of the state of anything. And so, it follows that it is natural to have a hard requirement on such analyses from a function pass. It turns out, that TargetLibraryInfo is just such an analysis, and InstCombine has a hard requirement on it. The approach I've taken here is to produce an analysis that models this flexibility by making it both a module and a function analysis. This exposes the fact that it is in fact safe to compute at any point. We can even make it a valid CGSCC analysis at some point if that is useful. However, we don't want to have a copy of the actual target library info state for each function! This state is specific to the triple. The somewhat direct and blunt approach here is to turn TLI into a pimpl, with the state and mutators in the implementation class and the query routines primarily in the wrapper. Then the analysis can lazily construct and cache the implementations, keyed on the triple, and on-demand produce wrappers of them for each function. One minor annoyance is that we will end up with a wrapper for each function in the module. While this is a bit wasteful (one pointer per function) it seems tolerable. And it has the advantage of ensuring that we pay the absolute minimum synchronization cost to access this information should we end up with a nice parallel function pass manager in the future. We could look into trying to mark when analysis results are especially cheap to recompute and more eagerly GC-ing the cached results, or we could look at supporting a variant of analyses whose results are specifically *not* cached and expected to just be used and discarded by the consumer. Either way, these seem like incremental enhancements that should happen when we start profiling the memory and CPU usage of the new pass manager and not before. The other minor annoyance is that if we end up using the TLI in both a module pass and a function pass, those will be produced by two separate analyses, and thus will point to separate copies of the implementation state. While a minor issue, I dislike this and would like to find a way to cleanly allow a single analysis instance to be used across multiple IR unit managers. But I don't have a good solution to this today, and I don't want to hold up all of the work waiting to come up with one. This too seems like a reasonable thing to incrementally improve later. llvm-svn: 226981
2015-01-24 10:06:09 +08:00
const TargetLibraryInfoImpl &TLIImpl)
: ImmutablePass(ID), TLIImpl(TLIImpl), TLI(this->TLIImpl) {
[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 18:41:28 +08:00
initializeTargetLibraryInfoWrapperPassPass(*PassRegistry::getPassRegistry());
}
[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 19:39:46 +08:00
char TargetLibraryAnalysis::PassID;
[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 18:41:28 +08:00
// Register the basic pass.
INITIALIZE_PASS(TargetLibraryInfoWrapperPass, "targetlibinfo",
"Target Library Information", false, true)
char TargetLibraryInfoWrapperPass::ID = 0;
void TargetLibraryInfoWrapperPass::anchor() {}