Fixes https://github.com/llvm/llvm-project/issues/115990.
MSVC mangling got inadvertently broken here,
https://github.com/llvm/llvm-project/pull/83997, when it was fixed what
decl context a lambda is apart of for uneval contexts.
https://godbolt.org/z/K6jb5v145 for reference.
Given the following code snippet
```
template <typename T>
concept C = requires(const T& t)
{
{ T::test([](){}) };
};
template<typename T, typename = void>
struct Widget;
template <C T>
struct Widget<T> {};
struct Baz
{
template<typename F>
static constexpr decltype(auto) test(F&& f) {}
};
void test()
{
Widget<Baz> w;
}
```
`Baz::test` has a deduced return type which means we must instantiate
that template even in an unevaluated context.
The lambda inside the concept is within the decl context of `struct
Widget<T> {};`. So we end up needing to mangle a name of
`Baz::test<Widget<template-type-0-0>::lambda()>>()` since the lambda
isn't apart of an instantiated substituted class `Widget` yet at the
point the lambda is instantiated.
Upon template instantation of `test` we end up asking for the mangled
name so we can add this instantiation to `CodeGenModule::DefferredDecls`
since `test` is now referenced but not yet used.
I think the longer term more correct solution is to key `DefferedDecls`
off of something else than the mangled name to avoid having to mangle
names for instantations that are referenced but will never be used since
they are only instantiated from an unevaluated context.
As a fix for the regression I just created a custom mangling scheme for
this case since MSVC has no comparable naming scheme as such a template
will never be emitted into the resulting obj as it will never be used.
Similar to arm_sve_vector_bits, the mangling of function types is
implemented as a pseudo template if there are any SME attributes
present, i.e.
`__SME_ATTRS<normal_function_type, sme_state>`
For example, the following function:
`void f(svint8_t (*fn)() __arm_streaming) { fn(); }`
would be mangled as:
`_Z1fP11__SME_ATTRSIFu10__SVInt8_tELj1EE`
See https://github.com/ARM-software/acle/pull/358
In MSVC, when `/d1initall` is enabled, `__declspec(no_init_all)` can be
applied to a type to suppress auto-initialization for all instances of
that type or to a function to suppress auto-initialization for all
locals within that function.
This change does the same for Clang, except that it applies to the
`-ftrivial-auto-var-init` flag instead.
NOTE: I did not add a Clang-specific spelling for this but would be
happy to make a followup PR if folks are interested in that.
This change is part of this proposal:
https://discourse.llvm.org/t/rfc-all-the-math-intrinsics/78294
- `Builtins.td` - Add f16 support for libm atan2 builtin
- `CGBuiltin.cpp` - Emit constraint atan2 intrinsic for clang builtin
- `clang/test/CodeGenCXX/builtin-calling-conv.cpp` - Use erff instead of
atan2 for clang builtin to lib call calling convention check, now that
atan2 maps to an intrinsic.
- add atan2 cases to llvm.experimental.constrained tests for more
backends: ARM, PowerPC, RISCV, SystemZ.
- LangRef.rst: add llvm.experimental.constrained.atan2, revise
llvm.atan2 description.
Last part of Implement the atan2 HLSL Function. Fixes#70096.
Features ebf16, memtag3, and rpres allow existing instructions to behave
differently depending on the value of certain control registers. FMV
does not read the content of control registers making these features
unsuitable for runtime dispatch. See the ACLE patch for more info:
https://github.com/ARM-software/acle/pull/355
Fixes: #113187
Avoid to create init function since clang does not support global
variable with flexible array init.
It will cause assertion failure later.
According to [P0533R9](https://wg21.link/P0533R9), the C++ standard
library functions corresponding to the C macros in `[c.math.abs]` are
now `constexpr`.
To implement this feature in libc++, we must make the built-in abs
function `constexpr`. This patch adds the implementation of a
`constexpr` abs function for the current constant evaluator and the new
bytecode interpreter.
It is important to note that in 2's complement systems, the absolute
value of the most negative value is out of range. In gcc, it will result
in an out-of-range error and will not be evaluated as constants. We
follow the same approach here.
In #99726, `-fptrauth-type-info-vtable-pointer-discrimination` was
introduced, which is intended to enable type and address discrimination
for type_info vtable pointers. However, some codegen logic for actually
enabling address discrimination was missing. This patch addresses the
issue.
Fixes#101716
We have a dedicated test to check the target-features for FMV
(clang/test/CodeGen/aarch64-fmv-dependencies.c) therefore I am removing
the autogenerated checks from irrelevant tests since the noise is making
it harder to review actual codegen changes.
According to https://developer.arm.com/documentation/102105/latest Arm
Architecture Reference Manual for A-profile architecture: Known issues
2.206 D22789
In section C5.2.25 "SSBS, Speculative Store Bypass Safe", under the
heading 'Configurations', the text that reads:
"This register is present only when FEAT_SSBS is implemented. Otherwise,
direct accesses to SSBS are UNDEFINED."
is changed to read:
"This register is present only when FEAT_SSBS2 is implemented.
Otherwise, direct accesses to SSBS are UNDEFINED."
This suggests that it's not worth splitting FEAT_SSBS2 from FEAT_SSBS in
the compiler, since FEAT_SSBS cannot be used for predicating the MRS/MSR
instructions. Those can access PSTATE.SSBS only when FEAT_SSBS2 is
available. Moreover, there are no hardware implementations which
implement FEAT_SSBS without FEAT_SSBS2, therefore unifying these
features in the specification should not be a regression for feature
detection.
Approved in ACLE as https://github.com/ARM-software/acle/pull/350
Summary:
This patch causes us to respect the `-fconvergent-functions` and
`-fno-convergent-functions` options correctly. GPU targets should have
this set all the time, but we now offer `-fno-convergent-functions` to
opt-out if you want to test broken behavior. This munged about with a
lot of the old weird logic, but I don't think it makes any real changes.
This was originally added in https://reviews.llvm.org/D142268 to have
LLDB display variable typenames that benefit from suppressing defaulted
template arguments.
We currently represent template aliases as `DW_AT_typedef`s instead of
`DW_TAG_template_alias`. This means for types like:
```
template <class _Tp>
using __remove_cv_t = __remove_cv(_Tp);
template <class _Tp>
using remove_cv_t = __remove_cv_t<_Tp>;
template<typename T>
class optional {
using value_type = T;
remove_cv_t<value_type> __val_;
}
```
we would generate DWARF like:
```
0x0000274f: DW_TAG_typedef
DW_AT_type (0x0000000000002758 "__remove_cv_t<value_type>")
DW_AT_name ("remove_cv_t<value_type>")
```
This is an actual libc++ type layout introduced in
https://github.com/llvm/llvm-project/pull/110355, and uncovered a
shortcoming of LLDB's data-formatter infrastructure, where we cache
formatters on the contents of `DW_AT_name` (which currently wouldn't be
a fully resolved typename for template specializations).
To unblock the libc++ change, I think we can revert this without much
fallout.
Then we have two options for follow-up (or do both):
1. reland this but adjust the LLDB formatter cache so it doesn't cache
formatters for template specializations
2. implement support for `DW_TAG_template_alias` in LLDB (and make Clang
generate them by default).
Fix#108015
The `mangleNameOrStandardSubstitution` function does not add the RD type
into the substitution, which causes the mangling of the \<base type\> to
be incorrect.
Rename `mangleNameOrStandardSubstitution` to `mangleCXXRecordDecl` and add `Record` as a substitution
This is primarily meant to address the issue identified in #109182,
around incorrect usage of `-fsycl-is-device`; we now have AMDGCN
flavoured SPIR-V which retains the desired behaviour around the default
AS and does not depend on the SYCL language being enabled to do so.
Overall, there are three changes:
1. We unconditionally use the `SPIRDefIsGen` AS map for AMDGCNSPIRV
target, as there is no case where the hack of setting default to private
would be desirable, and it can be used for languages other than OCL/HIP;
2. We implement `SPIRVTargetCodeGenInfo::getGlobalVarAddressSpace` for
SPIR-V in general, because otherwise using it from languages other than
HIP or OpenCL would yield 0, incorrectly;
3. We remove the incorrect usage of `-fsycl-is-device`.
And fix the diagnostics for __builtin_is_constant_evaluated(). We can be
in a non-constant context, but calling an immediate function always
makes the context constant for the duration of that call.
Set up these tests so these are marked as unsupported when targeting
z/OS. Most would already be unsupported if you ran lit on z/OS. However,
they also need to be unsupported if the default triple is z/OS.
The mangling compatibility being tested here changed between Clang 17
and 18, not between 16 and 17, so change the "old" version to 17.
As requested by @ahatanak in [post-commit
review](7421dd55a1 (commitcomment-128651446)).
An 'if' statement introduces a scope, but in some cases the conditional
branch to the then/else blocks had a debug-info attribution that did not
include the scope. This led to some inefficiency in the DWARF line
table.
Originally I tried spliting these features in the compiler with
https://github.com/llvm/llvm-project/pull/101712, but we decided to lump
those features in the ACLE specification (see
https://github.com/ARM-software/acle/pull/346). Since there are no
hardware implementations out there which implement ls64 without ls64_v
or ls64_accdata, this shouldn't be a regression for feature detection.
This implements our original design now that LLVM is comfortable with
structs and arrays of scalable vector types. All SVE ACLE intrinsics
already use struct types so the effect of this change is purely the
types used for alloca and function parameters.
There should be no C/C++ user visible change with this patch.
This patch enable the function multiversion(FMV) and `target_clones`
attribute for RISC-V target.
The proposal of `target_clones` syntax can be found at the
https://github.com/riscv-non-isa/riscv-c-api-doc/pull/48 (which has
landed), as modified by the proposed
https://github.com/riscv-non-isa/riscv-c-api-doc/pull/85 (which adds the
priority syntax).
It supports the `target_clones` function attribute and function
multiversioning feature for RISC-V target. It will generate the ifunc
resolver function for the function that declared with target_clones
attribute.
The resolver function will check the version support by runtime object
`__riscv_feature_bits`.
For example:
```
__attribute__((target_clones("default", "arch=+ver1", "arch=+ver2"))) int bar() {
return 1;
}
```
the corresponding resolver will be like:
```
bar.resolver() {
__init_riscv_feature_bits();
// Check arch=+ver1
if ((__riscv_feature_bits.features[0] & BITMASK_OF_VERSION1) == BITMASK_OF_VERSION1) {
return bar.arch=+ver1;
} else {
// Check arch=+ver2
if ((__riscv_feature_bits.features[0] & BITMASK_OF_VERSION2) == BITMASK_OF_VERSION2) {
return bar.arch=+ver2;
} else {
// Default
return bar.default;
}
}
}
```
Clang should only emit an available_externally vtable when there are no
unused virtual inline functions. Currently, if such such a function is
declared without inline inside the class, but is defined inline outside
the class, Clang might emit the vtable as available_externally. This
happens because Clang only considers the declarations of vtable entries,
but not the definitions. This patch addresses this by inspecting the
definitions in addition to the declarations.
Add nuw attribute to inbounds GEPs where the expression used to form the
GEP is an addition of unsigned indices.
Relands #105496, which was reverted because it exposed a miscompilation
arising from #98608. This is now fixed by #106512.
This was accidentally matching a metadata record that happend to have
three elements, but wasn't the record of interest. Add CHECKs to make
sure we've found the correct record.
As agreed on https://github.com/itanium-cxx-abi/cxx-abi/issues/109 these
placeholders should be mangled as a `template-prefix` production.
```
<template-prefix> ::= <template unqualified-name> # global template
::= <prefix> <template unqualified-name> # nested template
::= <template-param> # template template parameter
::= <substitution>
```
Previous to this patch, the template template parameter case was not
handled, and template template parameters were incorrectly being handled
as unqualified-names.
Before #95202, DeducedTemplateType was not canonicalized correctly, so
that template template parameter declarations were retained
uncanonicalized.
After #95202, they are correctly canonicalized, but this now leads to
these TTPs being anonymous entities, where the mangling implementation
correctly doesn't expect an anonymous declaration of this kind, leading
to a crash.
Fixes#106182.
For mobile applications, it's common for global destructors to never be
called (because the applications have their own lifecycle independent of
the standard C runtime), but threads are created and destroyed as normal
and so thread-local destructors are still called. -fno-static-c++-destructors
omits unnecessary global destructors, which is useful for code size, but
it also omits thread-local destructors, which is unsuitable. Add a
ternary `-fc++-static-destructors={all,none,thread-local}` option
instead to allow omitting only global destructors.
