aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Analysis/TargetLibraryInfo.cpp
AgeCommit message (Collapse)AuthorFilesLines
2025-07-25TargetLibraryInfo: Bring FreeBSD function list up to date (#144846)Gleb Popov1-0/+28
2025-07-15[TLI] Handle cabs without parameters gracefullyNikita Popov1-1/+1
Check that the function has at least one parameter before trying to access its type. Fixes https://github.com/llvm/llvm-project/issues/148770.
2025-06-26TargetLibraryInfo: Delete default TargetLibraryInfoImpl constructor (#145826)Matt Arsenault1-7/+1
It should not be possible to construct one without a triple. It would also be nice to delete TargetLibraryInfoWrapperPass, but that is more difficult.
2025-06-23[TLI] Add support for pvalloc() (#144949)Marco Elver1-0/+1
While pvalloc() is a legacy POSIX function, it remains widely available in common C libraries like glibc. Model pvalloc() in TargetLibraryInfo, allowing LLVM to correctly infer its attributes.
2025-06-17[AArch64][VecLib] Add libmvec support for AArch64 targets (#143696)Mary Kassayova1-0/+12
This patch adds support for the `libmvec` vector library on AArch64 targets. Currently, all `libmvec` functions in GLIBC version 2.40 are supported. The full list of math functions enabled can be found [here](https://github.com/bminor/glibc/blob/96abd59bf2a11ddd4e7ccaac840ec13c0b62d3ba/sysdeps/aarch64/fpu/Versions) (up to GLIBC 2.40). Previously, `libmvec` was only supported on x86_64 targets. Attempts to use it on AArch64 resulted in the following error from Clang: `unsupported option 'libmvec' for target 'aarch64'`.
2025-05-12[DirectX] Disable all libcalls for DXIL in TargetLibraryInfo.cpp (#138991)Deric C.1-0/+8
Fixes #138787 To the best of my knowledge, DXIL does not (and should not) support any of the libcalls in [`TargetLibraryInfo.def`](https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/Analysis/TargetLibraryInfo.def). Math libcalls are not used in HLSL and also do not have lowerings to DXIL. (The current implementation of math functions are done via intrinsics.) If there is a mistake with disabling all libcalls, then the libcalls we need can be re-enabled in a follow-up PR. --------- Co-authored-by: Justin Bogner <mail@justinbogner.com>
2025-05-07[LLVM][VecLib] Refactor LIBMVEC integration to be target neutral. (#138262)Paul Walker1-3/+10
Renames LIBMVEC-X86 to LIBMVEC and updates TLI to only add the existing x86 specific mapping when targeting x86.
2025-04-21[LLVM] Cleanup pass initialization for Analysis passes (#135858)Rahul Joshi1-9/+3
- Do not call pass initialization from pass constructors. - Instead, pass initialization should happen in the `initializeAnalysis` function. - https://github.com/llvm/llvm-project/issues/111767
2025-04-17[TLI] Use AArch64 vector calling convention for ArmPL routines (#135790)David Sherwood1-7/+7
Some ArmPL vector math routines that operate on fixed-width vector types obey the aarch64_vector_pcs calling convention, e.g. armpl_vsinq_f64, etc. This patch adds support for functions in the TLI to specify an optional calling convention to be added to the declared function. Once this patch lands I intend to follow up with a vectoriser patch that adds this optional calling convention when invoking the vector library variant from the loop vectoriser.
2025-03-06[IR] Store Triple in Module (NFC) (#129868)Nikita Popov1-4/+3
The module currently stores the target triple as a string. This means that any code that wants to actually use the triple first has to instantiate a Triple, which is somewhat expensive. The change in #121652 caused a moderate compile-time regression due to this. While it would be easy enough to work around, I think that architecturally, it makes more sense to store the parsed Triple in the module, so that it can always be directly queried. For this change, I've opted not to add any magic conversions between std::string and Triple for backwards-compatibilty purses, and instead write out needed Triple()s or str()s explicitly. This is because I think a decent number of them should be changed to work on Triple as well, to avoid unnecessary conversions back and forth. The only interesting part in this patch is that the default triple is Triple("") instead of Triple() to preserve existing behavior. The former defaults to using the ELF object format instead of unknown object format. We should fix that as well.
2024-12-12TargetLibraryInfo: Use pointer index size to determine getSizeTSize(). (#118747)Owen Anderson1-13/+10
When using non-integral pointer types, such as on CHERI targets, size_t is equivalent to the index size, which is allowed to be smaller than the size of the pointer.
2024-11-26[RISCV][SLEEF]: Support SLEEF vector library for RISC-V target. (#114014)Mark Goncharov1-0/+11
SLEEF math vector library now supports RISC-V target. Commit: https://github.com/shibatch/sleef/pull/477 This patch enables the use of auto-vectorization with subsequent replacement by the corresponding SLEEF function.
2024-11-13[TLI] Add support for reallocarray (#114818)serge-sans-paille1-0/+1
reallocarray is available in glibc since 2.29 under _DEFAULT_SOURCE and under _GNU_SOURCE before, let's model it appropriately.
2024-10-31[Reland][TLI] Add support for hypot libcall. (#114343)Kenji Mouri / 毛利 研二1-0/+2
This patch adds basic support for `hypot`. Constant folding support will be submitted in a subsequent patch. Related issue: https://github.com/llvm/llvm-project/issues/113711 Note: It's my first time contributing to the LLVM with encouragement from one of my friends, @fawdlstty. I learned a lot from https://github.com/llvm/llvm-project/pull/99611, and thanks for that. Note: I had created the same PR and merged (https://github.com/llvm/llvm-project/pull/113724), but reverted caused by the merging issue. (The CI issue happened in 3 A.M. at my timezone. So, I need to fall asleep again after I replied about why issue happened.) So, I rebased to the latest main branch and recreate the PR and hope I won't have the third time to create the same PR. I hope @arsenm can help me review the code again. I’m sorry for that. Kenji Mouri
2024-10-30Revert "[TLI] Add support for hypot libcall." (#114312)gulfemsavrun1-2/+0
Reverts llvm/llvm-project#113724
2024-10-30[TLI] Add support for hypot libcall. (#113724)Kenji Mouri / 毛利 研二1-0/+2
This patch adds basic support for `hypot`. Constant folding support will be submitted in a subsequent patch. Related issue: https://github.com/llvm/llvm-project/issues/113711 Note: It's my first time contributing to the LLVM with encouragement from one of my friends, @fawdlstty. I learned a lot from https://github.com/llvm/llvm-project/pull/99611, and thanks for that. Kenji Mouri
2024-10-20[TLI] Add basic support for scalbnxx (#112936)Fawdlstty1-0/+8
This patch adds basic support for `scalbln, scalblnf, scalblnl, scalbn, scalbnf, scalbnl`. Constant folding support will be submitted in a subsequent patch. Related issue: <#112631>
2024-10-18[TLI] Add support for the `ilogb` libcall. (#112725)c8ef1-0/+3
This patch adds the `ilogb` libcall. Constant folding will be handled in subsequent patches.
2024-09-20[TLI] Add basic support for fdim libcall (#108702)braw-lee1-0/+2
first PR to fix #108695 Signed-off-by: Kushal Pal <kushalpal109@gmail.com>
2024-08-13Enhance TLI detection of __size_returning_new lib funcs. (#102391)Snehasish Kumar1-1/+50
Previously the return types of __size_returning_new variants were not validated based on their members. This patch checks the members manually, also generalizes the size_t checks to be based on the module instead of being hardcoded. As requested in followup comment on https://github.com/llvm/llvm-project/pull/101564.
2024-08-06Add __size_returning_new variant detection to TLI. (#101564)Snehasish Kumar1-0/+4
Add support to detect __size_returning_new variants defined inproposal P0901R5 to extend to operator new, see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0901r5.html for details. This PR matches the declarations exported by tcmalloc in https://github.com/google/tcmalloc/blob/f2516691d01051defc558679f37720bba88d9862/tcmalloc/malloc_extension.h#L707-L711
2024-07-19[TLI] Add basic support for remquo libcall (#99611)Yingwei Zheng1-0/+2
This patch adds basic support for `remquo`. Constant folding support will be submitted in a subsequent patch. Related issue: https://github.com/llvm/llvm-project/issues/99497
2024-06-28[IR] Don't include Module.h in Analysis.h (NFC) (#97023)Nikita Popov1-0/+1
Replace it with a forward declaration instead. Analysis.h is pulled in by all passes, but not all passes need to access the module.
2024-05-24[NFC][LLVM] Clean up TLI VECFUNC macros. (#93178)Paul Walker1-0/+10
Move the undef'ing of library specific macros to the places in the code base where they are defined.
2024-05-21[AIX] Set memrchr to unavailable (#92588)Qiongsi Wu1-0/+3
`memrchr` is not available on AIX. This patch turns it off so the optimizer will not generate it to cause link errors.
2024-05-17TargetLibraryInfo: Assume no libcalls in the default constructor (#92400)Matt Arsenault1-20/+31
The only tricky point here is PlaceSafepoints has an awful hack where it's creating a legacy PassManager inside it's runImpl, which was not propagating the incoming TLI. This means there's an implicit bug fix, where PlaceSafepoints would have been treating too many calls as builtins. I'm trying to delete the default constructor altogether, but this seems to be more difficult.
2024-05-16PlaceSafepoints: Fix using default constructed TargetLibraryInfo (#92411)Matt Arsenault1-0/+4
2024-04-11PS support for erf/erff/erfl. (#88412)Sunil Srivastava1-3/+0
Co-authored-by: Sunil Srivastava <sunil.srivastava@sony.com>
2024-03-27[NFC][TLI] Move VecFuncs to statics to reduce stack usage (#86829)Alex MacLean1-62/+68
`TargetLibraryInfoImpl::addVectorizableFunctionsFromVecLib` has a lot of data in local stack arrays, which MSVC keeps on the stack even in release builds. To reduce stack usage, the data arrays (which are const), are moved outside the function as statics. This drops the method stack usage to be negligible.
2024-03-20Revert "Enable exp10 libcall on linux (#68736)"Nikita Popov1-9/+10
This reverts commit 9848fa4aa2a83b0fc3a93e5f905ef09c8dd85226. Causes buildbot failures.
2024-03-20Enable exp10 libcall on linux (#68736)Krishna Narayanan1-10/+9
2024-03-12[Analysis] Treat ldexpf() as missing on MinGW (#84748)Martin Storsjö1-0/+5
The function does exist, but it is a plain wrapper over regular ldexp(), so there's no benefit in calling it over regular ldexp(). Therefore, treat it as missing. This fixes builds of Wine for aarch64 with Clang in mingw mode, which regressed recently in 8d976c7f20fe8d92fe6f54af411594e15fac25ae. That commit unlocked transforming calls to ldexp into ldexpf, for some codepaths within Wine. Wine can use compilers in mingw mode without the regular mingw runtime libraries, which caused this to fail. (However, if the transformation to use ldexpf() would have made sense, the right fix would have been for Wine to provide a similar ldexpf->ldexp wrapper just like mingw does.)
2024-02-24[InstCombine] Handle more even/odd math functions (#81324)Artem Tyurin1-0/+3
At the moment this PR adds support only for `erf` function. Fixes #77220.
2024-02-15Adding support of AMDLIBM vector library (#78560)Rohit Aggarwal1-1/+13
Hi, AMD has it's own implementation of vector calls. This patch include the changes to enable the use of AMD's math library using -fveclib=AMDLIBM. Please refer https://github.com/amd/aocl-libm-ose --------- Co-authored-by: Rohit Aggarwal <Rohit.Aggarwal@amd.com>
2024-01-23[TLI] Remove leftover assert in TargetLibraryInfoImpl initialize (#79056)tltao1-6/+0
Remove unnecessary assert for a sorted StandardNames after implementation of getLibFunc is changed from binary search to a DenseMap Lookup in commit 7d950f040e3da66ec83f91b58d8c2220483d6335. The original getLibFunc binary search implementation is in commit c740e3f0d1ca9690100160ed2708d97d3c6562f0. Co-authored-by: Tony Tao <tonytao@ca.ibm.com>
2024-01-17 [llvm] Teach MachO about XROS (#78373)Cyndy Ishida1-0/+3
Add support for XROS to encode in Mach-O file formats.
2023-12-21[TLI] Add getLibFunc that accepts an Opcode and scalar Type. (#75919)Paschalis Mpeis1-0/+10
It sets a LibFunc similarly with the other two getLibFunc methods. Currently, it supports only the FRem Instruction. Add tests for FRem.
2023-11-22[IR][TLI] Cache getLibFunc() result on Function (NFC) (#72867)Nikita Popov1-2/+9
Cache the result of the TLI libfunc lookup in the Function object. This only caches the actual lookup of the LibFunc in the TLI map, but not the prototype validation, as that might differ between different TLI instances. This uses the existing mechanism for invalidating the intrinsic ID when the function name changes. The libfunc will be invalidated in that case as well. I don't believe this increases the size of Function on 64bit (which currently has a trailing `bool` member), and I don't think we would particularly care if it did, as Functions are uncommon as Values go.
2023-10-03[TLI] Added a guard for empty vector function name. (#68100)JolantaJensen1-0/+1
A guard for empty vector function name was removed in #66656. This patch adds the guard back.
2023-10-02Fix mechanism propagating mangled names for TLI function mappings (#66656)JolantaJensen1-17/+38
Currently the mappings from TLI are used to generate the list of available "scalar to vector" mappings attached to scalar calls as "vector-function-abi-variant" LLVM IR attribute. Function names from TLI are wrapped in mangled name following the pattern: _ZGV<isa><mask><vlen><parameters>_<scalar_name>[(<vector_redirection>)] The problem is the mangled name uses _LLVM_ as the ISA name which prevents the compiler to compute vectorization factor for scalable vectors as it cannot make any decision based on the _LLVM_ ISA. If we use "s" as the ISA name, the compiler can make decisions based on VFABI specification where SVE spacific rules are described. This patch is only a refactoring stage where there is no change to the compiler's behaviour.
2023-08-15[NFC][TLI] Replace std::lower_bound call in getLibFunc with DenseMap lookupDhruv Chawla1-5/+16
While std::lower_bound takes logarithmic time (relative to the length of the array) to execute, DenseMap gives better performance characteristics as it traverses few (if any) elements when collisions do occur, especially when the number of elements are known in advance. This gives a speedup of 0.24%: https://llvm-compile-time-tracker.com/compare.php?from=ac00cca3d9c6c3e9118ebbe47aa5b3ba1ee7404f&to=7f3d4c8ce8cee3a236a2328e46b2a8374672b46e&stat=instructions:u Differential Revision: https://reviews.llvm.org/D157951
2023-08-14[OSX][TargetLibraryInfo] Mark memrchr as unavailable on OSXPavel Kosov1-0/+1
On Mac OSX (tested version macOS 12.4, sdk 12.1) llvm can replace call to `strrchr()` with call to `memrchr()` when string length is known at compile time. This results in link error, because `memrchr` is not present in `libSystem`. It is needed to disable this optimization in `TargetLibraryInfo` for affected OSX versions. This non-standard function (`memrchr`) is not present on (at least) several versions of MacOS https://www.gnu.org/software/gnulib/manual/html_node/memrchr.html , so, in this patch `memrchr` is marked as unavailable for all versions. If someone knows versions where it should be available - please let me know. Github issue: https://github.com/llvm/llvm-project/issues/62254 Tests for this feature also cannot be easily added: https://reviews.llvm.org/D134134#3801747 ~~~ Huawei RRI, OS Lab Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D155168
2023-07-12[TLI][AArch64] Add mappings to vectorized functions from ArmPLMaciej Gabka1-1/+20
Arm Performance Libraries contain math library which provides vectorized versions of common math functions. This patch allows to use it with clang and llvm via -fveclib=ArmPL or -vector-library=ArmPL, so loops with such calls can be vectorized. The executable needs to be linked with the amath library. Arm Performance Libraries are available at: https://developer.arm.com/Tools%20and%20Software/Arm%20Performance%20Libraries Reviewed by: paulwalker-arm Differential Revision: https://reviews.llvm.org/D154508
2023-04-28[MemProf] Use updated version of hot/cold operator newTeresa Johnson1-8/+8
Switch to the just updated versions of the API in tcmalloc that change the name of the hot cold paramter to a reserved identifier __hot_cold_t. This was based on feedback from Richard Smith, as I also need to add some follow-on handling to clang so they are annotated properly. Differential Revision: https://reviews.llvm.org/D149475
2023-04-19[MemProf] Optionally pass hot/cold hints to operator newTeresa Johnson1-0/+8
Optionally (off by default) replace operator new() calls marked with a hot or cold memprof attribute with an operator new() call that takes a hot_cold_t parameter. Currently this is supported by the open source version of tcmalloc, see: https://github.com/google/tcmalloc/blob/master/tcmalloc/new_extension.h Differential Revision: https://reviews.llvm.org/D148718
2023-03-29[TLI][AArch64] Extend SLEEF vectorized functions mapping with VLA functionsPaul Osmialowski1-4/+12
This commit extends D134719 "[AArch64] Enable libm vectorized functions via SLEEF" with the mappings for the scalable functions. It also introduces all the necessary changes needed to support masked interfaces. Reviewed By: danielkiss, sdesmalen Differential Revision: https://reviews.llvm.org/D146839
2023-03-29Revert "[TLI][AArch64] Extend SLEEF vectorized functions mapping with VLA ↵Paul Osmialowski1-12/+4
functions" Reverting it so I could land it with Arcanist. This reverts commit 59dcf927ee43e995374907b6846b657f68d7ea49.
2023-03-29[TLI][AArch64] Extend SLEEF vectorized functions mapping with VLA functionsPaul Osmialowski1-4/+12
This commit extends D134719 "[AArch64] Enable libm vectorized functions via SLEEF" with the mappings for the scalable functions. It also introduces all the necessary changes needed to support masked interfaces. Signed-off-by: Paul Osmialowski <pawel.osmialowski@arm.com>
2023-02-07[NFC][TargetParser] Remove llvm/ADT/Triple.hArchibald Elliott1-1/+1
I also ran `git clang-format` to get the headers in the right order for the new location, which has changed the order of other headers in two files.
2023-01-20[AArch64] Enable libm vectorized functions via SLEEFDaniel Kiss1-3/+26
It enables trigonometry functions vectorization via SLEEF: http://sleef.org/. - A new vectorization library enum is added to TargetLibraryInfo.h: SLEEF. - A new option is added to TargetLibraryInfoImpl - ClVectorLibrary: SLEEF. - A comprehensive test case is included in this changeset. - A new vectorization library argument is added to -fveclib: -fveclib=SLEEF. Trigonometry functions that are vectorized by sleef: acos asin atan atanh cos cosh exp exp2 exp10 lgamma log10 log2 log sin sinh sqrt tan tanh tgamma Co-authored-by: Stefan Teleman Reviewed By: paulwalker-arm Differential Revision: https://reviews.llvm.org/D134719