For the Itanium ABI, we emit an initializer for each module. This is responsible
for handling initialization of global vars. Relates to P1874R1.
The initializer has a known mangling and is automatically called from any TU that
imports a module. Since, at present, the importer has no way to determine that an
imported module does not require an initializer, we generate the initializer for
all cases (even when it is empty).
Initializers must be run once, with the ordering guaranteed by the import graph
and this is ensured in the current code by addition of a guard variable.
In the case that a module has no requirement for global initializers, and also does
not import any other modules, we can elide the guard variable.
Differential Revision: https://reviews.llvm.org/D134589
std::optional::value() has undesired exception checking semantics and is
unavailable in older Xcode (see _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS). The
call sites block std::optional migration.
This makes `ninja clang` work in the absence of llvm::Optional::value.
This change:
- Modifies the ACLE code to allow the new SLC value (3) for the prefetch
target.
- Introduces a new intrinsic, @llvm.aarch64.prefetch which matches the
PRFM family instructions much more closely, and can represent all
values for the PRFM immediate.
The target-independent @llvm.prefetch intrinsic does not have enough
information for us to be able to lower to it from the ACLE intrinsics
correctly.
- Lowers the acle calls to the new intrinsic on aarch64 (the ARM
lowering is unchanged).
- Implements code generation for the new intrinsic in both SelectionDAG
and GlobalISel. We specifically choose to continue to support lowering
the target-independent @llvm.prefetch intrinsic so that other
frontends can continue to use it.
Differential Revision: https://reviews.llvm.org/D139443
After this patch, in the following snippet:
```
template <typename T> Foo {};
template <template <typename T> class CT = Foo> Bar {};
Bar<> b;
```
The debug-info entry for the `CT` template parameter will have
a `DW_AT_default_value (true)` attached to it.
Differential Revision: https://reviews.llvm.org/D139989
DWARFv5 added support for labelling template parameters with
DW_AT_default_value to indicate whether the particular instantiation
defaulted parameter. The current implementation only supports a limited
set of possible cases. Namely for non-value-dependent integral template
parameters and simple type template parameters.
Useful cases that don't work are:
1. Type template parameters with defaults that are
themselves templates. E.g.,
```
template<typename T1, typename T2 = Foo<T1>> class C1;
template<typename T = Foo<int>> class C2;
etc.
```
2. Template template parameters
`clang::isSubstitutedDefaultArgument` already implement the required logic
to determine whether a template argument is defaulted. This patch re-uses
this logic for DWARF CodeGen.
Differential Revision: https://reviews.llvm.org/D139988
This change will allow users to call getNullability() without providing an ASTContext.
Reviewed By: gribozavr2
Differential Revision: https://reviews.llvm.org/D140104
This reverts commit 731abdfdcc33d813e6c3b4b89eff307aa5c18083.
This commit breaks some tests in libcxx, e.g.
`std/utilities/expected/expected.expected/ctor/ctor.inplace.pass.cpp`
RecordLayoutBuilder assumes the size of a potentially-overlapping field
with non-zero size as the size of the base subobject type corresponding
to the field type.
Make CGRecordLayoutBuilder to acknowledge that in order to avoid incorrect
padding insertion.
Differential Revision: https://reviews.llvm.org/D139741
**Summary**
Starting with DWARFv5, DW_AT_default_value can be used to indicate
that a template argument has a default value. With this patch Clang
will attach the attribute to the debug metadata regardless of version.
In a follow-up patch we will change llvm to emit this attribute in
earlier versions of DWARF, unless compiling with -gstrict-dwarf.
**Details**
* Previously the DwarfVersion check in CGDebugInfo was inconsistent:
For non-type template arguments we attached the attribute to the debug
metadata in DWARFv5 only. Whereas for type template arguments we didn't
have such a version restriction. With this patch we attach the attribute
regardless of DWARF version (and instead offload the check to the AsmPrinter
in a future patch).
This patch implements P0960R3, which allows initialization of aggregates
via parentheses.
As an example:
```
struct S { int i, j; };
S s1(1, 1);
int arr1[2](1, 2);
```
This patch also implements P1975R0, which fixes the wording of P0960R3
for single-argument parenthesized lists so that statements like the
following are allowed:
```
S s2(1);
S s3 = static_cast<S>(1);
S s4 = (S)1;
int (&&arr2)[] = static_cast<int[]>(1);
int (&&arr3)[2] = static_cast<int[2]>(1);
```
This patch was originally authored by @0x59616e and completed by
@ayzhao.
Fixes#54040, Fixes#54041
Co-authored-by: Sheng <ox59616e@gmail.com>
Full write up : https://discourse.llvm.org/t/c-20-rfc-suggestion-desired-regarding-the-implementation-of-p0960r3/63744
Reviewed By: ilya-biryukov
Differential Revision: https://reviews.llvm.org/D129531
This may be a breaking change for consumers if they're trying to detect
if code is C or C++, since it'll start using new codes that they may not
be ready to recognize, in which case they may fall back to non-C
handling.
This caused regressions due to PS4 having a different default for C
language version than other targets. Those tests were adapted to be
relaxed about which C version is used.
This reapplies commit 3c312e48f325c1b1ee11404ee6cfa08ee00037b0
Which was reverted by commit 6ab6085c77ef9bcdabf842342f63fba4291791a4.
Differential Revision: https://reviews.llvm.org/D138597
This patch moves some of the logic on how to emit target region functions and
adds emitTargetRegionFunction to the OpenMPIRBuilder. Also the
OpenMPOffloadMandatory flag is added to the config.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D139634
This reverts commit 107ee2613063183cb643cef97f0fad403508c9f0 to facilitate
investigating and fixing the root cause.
Differential Revision: https://reviews.llvm.org/D135269
Added codegen for `omp error` directive.
This is to generate IR to call:
void __kmpc_error(ident_t *loc, int severity, const char *message);
Differential Revision: https://reviews.llvm.org/D139166
Prior to this, metadata pertaining to the size or address point offsets
into a relative vtable were twice the value they should be (treating
component widths as pointer width rather than 4 bytes). This prevented
some vtables from being devirtualized with D134320. This ensures the
correct metadata is written so whole program devirtualization can catch
these remaining devirt targets.
Differential Revision: https://reviews.llvm.org/D134687
The global constant arguments could be in a different address space
than the first argument, so we have to add another overloaded argument.
This patch was originally made for CHERI LLVM (where globals can be in
address space 200), but it also appears to be useful for in-tree targets
as can be seen from the test diffs.
Differential Revision: https://reviews.llvm.org/D138722
We've exploited test data class instructions introduced in ISA 3.0.
This change unifies the scalar intrinsics into ppc_test_data_class
and add support for 128-bit precision float values using xststdcqp.
Vector versions of the intrinsic can't be unified because they return
vector int instead of int.
Reviewed By: shchenz
Differential Revision: https://reviews.llvm.org/D138105
Some buildbots are failing in Clang and LLDB tests. (I guess the LLDB
failure is due to the explicit C language tests in DwarfUnit.cpp that
need to be updated - not sure what the Clang failures are about, they
seem to be still emitting C99 when we're expecting C11 and I checked
those tests pass... maybe systems with a different C language version
default?)
This reverts commit 3c312e48f325c1b1ee11404ee6cfa08ee00037b0.
This may be a breaking change for consumers if they're trying to detect
if code is C or C++, since it'll start using new codes that they may not
be ready to recognize, in which case they may fall back to non-C
handling.
Differential Revision: https://reviews.llvm.org/D138597
On SystemZ, the vector ABI changes depending on the presence of hardware
vector support. Therefore, each binary compiled with a visible vector ABI
(e.g. one that calls an external function with a vector argument) should be
marked with a .gnu_attribute describing this.
Reviewed By: uweigand
Differential Revision: https://reviews.llvm.org/D105067
This only contains the SelectionDAG implementation. GlobalISel to
follow.
The broad approach is:
- Introduce new builtins for 128-bit wide instructions.
- Lower these to @llvm.read_register.i128/@llvm.write_register.i128
- Introduce target-specific ISD nodes which have legal operands (two
i64s rather than an i128). These are named AArch64::{MRRS, MSRR} to
match the instructions they are for. These are a little complex as
they need to match the "shape" of what they're replacing or the
legaliser complains.
- Select these using the existing tryReadRegister/tryWriteRegister to
share the MDString parsing code, and introduce additional code to
ensure these are selected into the right MRRS/MSRR instructions. What
makes this hard is ensuring that the two i64s end up in an XSeqPair
register pair, because SelectionDAG doesn't care that much about
register classes if it can avoid doing so.
The main change to existing code is the reorganisation of
tryReadRegister and tryWriteRegister to try to keep the string parsing
code separate from the instruction creating code.
This also includes the changes to clang to define and use the ACLE
feature macro named `__ARM_FEATURE_SYSREG128`.
Contributors:
Sam Elliott
Lucas Prates
Differential Revision: https://reviews.llvm.org/D139086
Msan needs noundef consistency between interface and implementation. If
we call C++ from C we can have noundef on C++ side, and no noundef on
caller C side, noundef implementation will not set TLS for return value,
no noundef caller will expect it. Then we have false reports in msan.
The workaround could be set TLS to zero even for noundef return values.
However if we do that always it will increase binary size by about 10%.
If we do that selectively we need to handle "address is taken"
functions, any non local functions, and probably all function which have
musttail callers. Which is still a lot.
The existing implementation of HasStrictReturn refers to C standard as
the reason not enforcing noundef. I believe it applies only to the case
when return statement is omitted. Testing on Google codebase I never see
such cases, however I've see tens of cases where C code returns actual
uninitialized variables, but we ignore that it because of "omitted
return" case.
So this patch will:
1. fix false-positives with TLS missmatch.
2. detect bugs returning uninitialized variables for C as well.
3. report "omitted return" cases stricter than C, which is already a
warning and very likely a bug in a code anyway.
Reviewed By: kda
Differential Revision: https://reviews.llvm.org/D139296
Currently per-function metadata consists of:
(start-pc, size, features)
This adds a new UAR feature and if it's set an additional element:
(start-pc, size, features, stack-args-size)
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D136078
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
