aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Transforms/Utils/BuildLibCalls.cpp
AgeCommit message (Collapse)AuthorFilesLines
2025-06-23[TLI] Add support for pvalloc() (#144949)Marco Elver1-1/+3
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-04-12[LibCall] Infer nocallback for libcalls (#135173)Yingwei Zheng1-1/+38
This patch adds `nocallback` attributes for string/math libcalls. It allows FuncAttributor to infer `norecurse` more precisely and encourages more aggressive global optimization.
2025-03-24Reland "[Transforms] LoopIdiomRecognize recognize strlen and wcslen #108985" ↵Henry Jiang1-0/+9
(#132572) Reland https://github.com/llvm/llvm-project/pull/108985 Extend `LoopIdiomRecognize` to find and replace loops of the form ```c base = str; while (*str) ++str; ``` and transforming the `strlen` loop idiom into the appropriate `strlen` and `wcslen` library call which will give a small performance boost if replaced. ```c str = base + strlen(base) len = str - base ```
2025-03-22Revert "Reland "[Transforms] LoopIdiomRecognize recognize strlen and wcslen ↵Martin Storsjö1-9/+0
(#108985)" (#131412)" This reverts commit ac9049df7e62e2ca4dc5d103593b51639b5715e3. This change broke Wine (causing it to hang on startup), see https://github.com/llvm/llvm-project/pull/108985 for discussion.
2025-03-21Reland "[Transforms] LoopIdiomRecognize recognize strlen and wcslen ↵Henry Jiang1-0/+9
(#108985)" (#131412) Relands https://github.com/llvm/llvm-project/pull/108985 This PR continues the effort made in https://discourse.llvm.org/t/rfc-strlen-loop-idiom-recognition-folding/55848 and https://reviews.llvm.org/D83392 and https://reviews.llvm.org/D88460 to extend `LoopIdiomRecognize` to find and replace loops of the form ```c base = str; while (*str) ++str; ``` and transforming the `strlen` loop idiom into the appropriate `strlen` and `wcslen` library call which will give a small performance boost if replaced. ```c str = base + strlen(base) len = str - base ```
2025-03-14Revert "[Transforms] LoopIdiomRecognize recognize strlen and wcslen ↵Henry Jiang1-9/+0
(#108985)" (#131405) This reverts commit bf6357f0f51eccc48b92a130afb51c0280d56180.
2025-03-14[Transforms] LoopIdiomRecognize recognize strlen and wcslen (#108985)Henry Jiang1-0/+9
This PR continues the effort made in https://discourse.llvm.org/t/rfc-strlen-loop-idiom-recognition-folding/55848 and https://reviews.llvm.org/D83392 and https://reviews.llvm.org/D88460 to extend `LoopIdiomRecognize` to find and replace loops of the form ```c base = str; while (*str) ++str; ``` and transforming the `strlen` loop idiom into the appropriate `strlen` and `wcslen` library call which will give a small performance boost if replaced. ```c str = base + strlen(base) len = str - base ``` --------- Co-authored-by: Michael Kruse <github@meinersbur.de>
2025-03-13[InferAttrs] Refine attributes for a few libc routinesAntonio Frighetto1-7/+8
Attributes inference has been improved for a few functions. Particularly, ldexp and variants, as well as abort, may be marked as `nounwind`, as they do not propagate any exceptions to the caller, neither they unwind the stack. Besides, fwrite and fread first argument should be respectively readonly and writeonly.
2025-03-13[InferAttrs] Mark floating-point libcalls as `errno`-writingAntonio Frighetto1-41/+67
Floating-point libcalls are currently conservatively marked as may write any memory. Restrict these to clobber only `errno`.
2025-03-12[BuildLibCalls] Add helper for setting memory effects (NFC)Nikita Popov1-10/+14
Remove reliance on having dedicated setters and getters on Function for every possible memory effect combination.
2025-01-29[IR] Convert from nocapture to captures(none) (#123181)Nikita Popov1-2/+3
This PR removes the old `nocapture` attribute, replacing it with the new `captures` attribute introduced in #116990. This change is intended to be essentially NFC, replacing existing uses of `nocapture` with `captures(none)` without adding any new analysis capabilities. Making use of non-`none` values is left for a followup. Some notes: * `nocapture` will be upgraded to `captures(none)` by the bitcode reader. * `nocapture` will also be upgraded by the textual IR reader. This is to make it easier to use old IR files and somewhat reduce the test churn in this PR. * Helper APIs like `doesNotCapture()` will check for `captures(none)`. * MLIR import will convert `captures(none)` into an `llvm.nocapture` attribute. The representation in the LLVM IR dialect should be updated separately.
2024-12-21Revert "SimplifyLibCalls: Use default globals address space when building ↵Owen Anderson1-68/+48
new global strings. (#118729)" (#119616) This reverts commit cfa582e8aaa791b52110791f5e6504121aaf62bf.
2024-12-06SimplifyLibCalls: Use default globals address space when building new global ↵Owen Anderson1-55/+74
strings. (#118729) Writing a test for this transitively exposed a number of places in BuildLibCalls where we were failing to propagate address spaces properly, which are additionally fixed.
2024-11-13[TLI] Add support for reallocarray (#114818)serge-sans-paille1-0/+14
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/+3
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-3/+0
Reverts llvm/llvm-project#113724
2024-10-30[TLI] Add support for hypot libcall. (#113724)Kenji Mouri / 毛利 研二1-0/+3
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-29[TLI] Add support for the `tgamma` libcall. (#113791)c8ef1-0/+3
This patch adds the `tgamma` libcall.
2024-10-20[TLI] Add basic support for scalbnxx (#112936)Fawdlstty1-0/+6
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-10-01[llvm][opt][Transforms] Replacement `calloc` should match replaced `malloc` ↵Alex Voicu1-3/+3
(#110524) Currently DSE unconditionally emits `calloc` as returning a pointer to AS0. However, this is incorrect for targets that have a non-zero default AS, as it'd not match the `malloc` signature. This patch addresses that by piping through the AS for the pointer returned by `malloc` into the `calloc` insertion call.
2024-09-20[TLI] Add basic support for fdim libcall (#108702)braw-lee1-0/+3
first PR to fix #108695 Signed-off-by: Kushal Pal <kushalpal109@gmail.com>
2024-09-18[TLI] Support inferring function attributes for sincos[f|l] (#108554)Benjamin Maxwell1-0/+12
2024-08-18[TLI] Add support for inferring attr `cold`/`noreturn` on `std::terminate` ↵Noah Goldstein1-0/+18
and `__cxa_throw` These functions are both inherently on the error path so `cold` seems appropriate. `noreturn` is definitional. Closes #101622
2024-08-15Allow optimization of __size_returning_new variants. (#102258)Snehasish Kumar1-0/+51
https://github.com/llvm/llvm-project/pull/101564 added support to TLI to detect variants of operator new which provide feedback on the actual size of memory allocated (http://wg21.link/P0901R5). This patch extends SimplifyLibCalls to handle hot cold hinting of these variants.
2024-08-01[TLI] Add support for nan libfunc (#101356)Yingwei Zheng1-0/+3
Reference: https://en.cppreference.com/w/cpp/numeric/math/nan
2024-07-30[TLI] Add support for inferring attr `cold` on `exit`/`abort`Noah Goldstein1-0/+12
`abort` can be assumed always cold and assume non-zero `exit` status as a `cold` path as well. Closes #101003
2024-07-19[TLI] Add basic support for remquo libcall (#99611)Yingwei Zheng1-0/+5
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-07-19[InferAttrs] Set attributes for `remainder` (#99521)Yingwei Zheng1-0/+3
Fixes one of the issues in https://github.com/llvm/llvm-project/issues/99497.
2024-04-29[CodeGen][i386] Move -mregparm storage earlier and fix Runtime calls (#89707)Kees Cook1-1/+1
When building the Linux kernel for i386, the -mregparm=3 option is enabled. Crashes were observed in the sanitizer handler functions, and the problem was found to be mismatched calling convention. As was fixed in commit c167c0a4dcdb ("[BuildLibCalls] infer inreg param attrs from NumRegisterParameters"), call arguments need to be marked as "in register" when -mregparm is set. Use the same helper developed there to update the function arguments. Since CreateRuntimeFunction() is actually part of CodeGenModule, storage of the -mregparm value is also moved to the constructor, as doing this in Release() is too late. Fixes: https://github.com/llvm/llvm-project/issues/89670
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.
2023-11-15[BuildLibCalls] Use getPtrTy instead of getInt8PtrTyBjorn Pettersson1-60/+62
Stop using getInt8PtrTy() when referring to char* types when building libcalls. As in many other files we can simply use getPtrTy() instead, as part of transition into opaque pointers. This patch is using thing like Type *CharPtrTy = B.getPtrTy(); Type *VoidPtrTy = B.getPtrTy(); in several places, to give the pointer type a name. The idea is to make the mapping to the libc function prototypes clear.
2023-08-03[llvm] Drop some typed pointer handling/bitcastsBjorn Pettersson1-30/+23
Differential Revision: https://reviews.llvm.org/D157016
2023-04-19[MemProf] Optionally pass hot/cold hints to operator newTeresa Johnson1-0/+84
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-04-19[InferAttrs] Mark frexp and modf as memory(argmem: write)Daniel Woodworth1-0/+4
These two math library functions can't write to errno, but they do produce two results and store the second result to a pointer passed as their second argument. Appropriately marking them as memory(argmem: write) enables more optimizations on calls to them. Reviewed By: xbolva00 Differential Revision: https://reviews.llvm.org/D148043
2022-12-20[BuildLibCalls][RISCV] Sign extend return value of bcmp on riscv64.Craig Topper1-0/+9
riscv64 wants callees to sign extend signed and unsigned int returns. The caller can use this to avoid a sign extend if the result is used by a comparison since riscv64 only has 64-bit compares. InstCombine/SimplifyLibCalls aggressively turn memcmps that are only used by an icmp eq 0 into bcmp, but we lose the signext attribute that would have been present on the memcmp. This causes an unneeded sext.w in the generated assembly. This looks even sillier if bcmp is implemented alias to memcmp. In that case, not only did we not get any savings by using bcmp, we added an instruction. This probably applies to other functions, this just happens to be the one I noticed so far. See also the discussion here https://discourse.llvm.org/t/can-we-preserve-signext-return-attribute-when-converting-memcmp-to-bcmp/67126 Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D139901
2022-12-09[MemoryBuiltins] Remove unused TLI parameters (NFC)Nikita Popov1-1/+1
2022-12-02Attributes: convert Optional to std::optionalKrzysztof Parzyszek1-5/+6
2022-11-04[IR] Switch everything to use memory attributeNikita Popov1-5/+0
This switches everything to use the memory attribute proposed in https://discourse.llvm.org/t/rfc-unify-memory-effect-attributes/65579. The old argmemonly, inaccessiblememonly and inaccessiblemem_or_argmemonly attributes are dropped. The readnone, readonly and writeonly attributes are restricted to parameters only. The old attributes are auto-upgraded both in bitcode and IR. The bitcode upgrade is a policy requirement that has to be retained indefinitely. The IR upgrade is mainly there so it's not necessary to update all tests using memory attributes in this patch, which is already large enough. We could drop that part after migrating tests, or retain it longer term, to make it easier to import IR from older LLVM versions. High-level Function/CallBase APIs like doesNotAccessMemory() or setDoesNotAccessMemory() are mapped transparently to the memory attribute. Code that directly manipulates attributes (e.g. via AttributeList) on the other hand needs to switch to working with the memory attribute instead. Differential Revision: https://reviews.llvm.org/D135780
2022-10-04[LibCalls] Cast Char argument to 'int' before calling emitFPutCBjorn Pettersson1-2/+0
The helpers in BuildLibCalls normally expect that the Value arguments already have the correct type (matching the lib call signature). And exception has been emitFPutC which casted the Char argument to 'int' using CreateIntCast. This patch moves the cast to the caller instead of doing it inside emitFPutC. I think it makes sense to make the BuildLibCall API:s a bit more consistent this way, despite the need to handle the int cast in two different places now. Differential Revision: https://reviews.llvm.org/D135066
2022-10-04[BuildLibCalls] Use TLI to get 'int' and 'size_t' type sizesBjorn Pettersson1-59/+53
Stop assuming that an 'int' is 32 bits in helpers that emit libcalls to lib functions that had 'int' in the signature. For most targets this is NFC. For a target with 16 bit 'int' type this could help out detecting if trying to emit a libcall with incorrect signature. Similarly we now derive the type mapping to 'size_t' by asking TLI about the size of 'size_t'. This should be NFC (at least for in-tree targets) since getSizeTSize(), in TLI, is deriving the size in the same way as DataLayout::getIntPtrType(). Differential Revision: https://reviews.llvm.org/D135065
2022-10-04[BuildLibCalls] Name types to identify when 'int' and 'size_t' is assumed. NFCBjorn Pettersson1-55/+98
Lots of BuildLibCalls helpers are using Builder::getInt32Ty to get a type matching an 'int', and DataLayout::getIntPtrType to get a type matching 'size_t'. The former is not true for all targets, since and 'int' isn't always 32 bits. And the latter is a bit weird as well as the definition of DataLayout::getIntPtrType isn't clearly mapping it to 'size_t'. This patch is not aiming at solving any such problems. It is merely highlighting when a libcall is expecting to use 'int' and 'size_t' by naming the types as IntTy and SizeTTy when preparing the type signatures for the emitted libcalls. Differential Revision: https://reviews.llvm.org/D135064
2022-08-16[InstCombine] Remove assumptions about int having 32 bitsMartin Sebor1-8/+5
Reviewed By: bjope Differential Revision: https://reviews.llvm.org/D131731
2022-08-08[llvm] LLVM_FALLTHROUGH => [[fallthrough]]. NFCFangrui Song1-7/+7
With C++17 there is no Clang pedantic warning or MSVC C5051.
2022-07-21BuildLibCalls: move inference of freeing memory laterAugie Fackler1-113/+115
This probably should have been part of D123089, but the effects of it don't show up until we start removing functions from the table in D130107. Oops. Differential Revision: https://reviews.llvm.org/D130184
2022-07-01[InstCombine] Transform strrchr to memrchr for constant stringsMartin Sebor1-0/+10
Add an emitter for the memrchr common extension and simplify the strrchr call handler to use it. This enables transforming calls with the empty string to the test C ? S : 0. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D128954
2022-05-31BuildLibCalls: infer allockind attributes on relevant functionsAugie Fackler1-0/+15
Differential Revision: https://reviews.llvm.org/D123089
2022-05-10[BuildLibCalls] infer inreg param attrs from NumRegisterParametersNick Desaulniers1-0/+40
We're having a hard time booting the ARCH=i386 Linux kernel with clang after removing -ffreestanding because instcombine was dropping inreg from callers during libcall simplification, but not the callees defined in different translation units. This led the callers and callees to have wildly different calling conventions, which (predictably) blew up at runtime. Infer the inreg param attrs on function declarations from the module metadata "NumRegisterParameters." This allows us to boot the ARCH=i386 Linux kernel (w/ -ffreestanding removed). Fixes: https://github.com/llvm/llvm-project/issues/53645 Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D125285
2022-05-03BuildLibCalls: simplify switch statement slightlyAugie Fackler1-12/+8
Per feedback on D123086 after submit. Also added a test for vec_malloc et al attribute inference to show it's doing the right thing. The new tests exposed a defect, corrected by adding vec_free to the list of free functions in MemoryBuiltins.cpp, which had been overlooked all the way back in D94710, over a year ago. Differential Revision: https://reviews.llvm.org/D124859
2022-05-02Reapply "[BuildLibCalls] Introduce getOrInsertLibFunc() for use when buildingJonas Paulsson1-90/+198
libcalls." (was 0f8c626). This reverts commit 14d9390. The patch previously failed to recognize cases where user had defined a function alias with an identical name as that of the library function. Module::getFunction() would then return nullptr which is what the sanitizer discovered. In this updated version a new function isLibFuncEmittable() has as well been introduced which is now used instead of TLI->has() anytime a library function is to be emitted . It additionally also makes sure there is e.g. no function alias with the same name in the module. Reviewed By: Eli Friedman Differential Revision: https://reviews.llvm.org/D123198