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.
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](96abd59bf2/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'`.
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>
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.
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.
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.
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.
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
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>
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.
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.
`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.
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.)
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>
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>
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.
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.
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
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
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
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
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>
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
