This change is needed when lowering alloca()-using code on targets
such as ROCDL that represent private scratch space as a separate
address space.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D119775
The `__builtin_pdepd` and `__builtin_pextd` are P10 builtins that are meant to
be used under 64-bit only. For instance, when the builtins are compiled under
32-bit mode:
```
$ cat t.c
unsigned long long foo(unsigned long long a, unsigned long long b) {
return __builtin_pextd(a,b);
}
$ clang -c t.c -mcpu=pwr10 -m32
ExpandIntegerResult #0: t31: i64 = llvm.ppc.pextd TargetConstant:i32<6928>, t28, t29
fatal error: error in backend: Do not know how to expand the result of this operator!
```
This patch adds sema checking for these builtins to compile under 64-bit
mode only and on P10. The builtins will emit a diagnostic when they are compiled on
non-P10 compilations and on 32-bit mode.
Differential Revision: https://reviews.llvm.org/D118753
EQUIVALENCE storage association of objects whose types are not
both default-kind numeric storage sequences, or not both default-kind
character storage sequences, are not standard conformant.
However, most Fortran compilers admit such usage, with warnings
in strict conformance mode. This patch allos EQUIVALENCE of objects
that have sequence types that are either identical, both numeric
sequences (of default kind or not), or both character sequences.
Non-sequence types, and sequences types that are not homogeneously
numeric or character, remain errors.
Differential Revision: https://reviews.llvm.org/D119848
Our best guess is that the two syntaxes should have exactly equivalent
effects, so, let's be consistent with what we do in libcxx/include/.
I've left `#include "include/x.h"` and `#include "../y.h"` alone
because I'm less sure that they're interchangeable, and they aren't
inconsistent with libcxx/include/ because libcxx/include/ never
does that kind of thing.
Also, use the `_LIBCPP_PUSH_MACROS/POP_MACROS` dance for `<__undef_macros>`,
even though it's technically unnecessary in a standalone .cpp file,
just so we have consistently one way to do it.
Differential Revision: https://reviews.llvm.org/D119561
`Shutdown.h` was transitively depending on two headers, but this isn't
allowed under a modules build, so they're now explicitly included.
Differential Revision: https://reviews.llvm.org/D119806
When a pointer assignment with bounds remapping has a function
reference as its right-hand side, don't check for array conformance.
Differential Revision: https://reviews.llvm.org/D119845
https://maskray.me/blog/2022-01-16-archives-and-start-lib
For every definition in an extracted archive member, we intern the symbol twice,
once for the archive index entry, once for the .o symbol table after extraction.
This is inefficient.
Symbols in a --start-lib ObjFile/BitcodeFile are only interned once because the
result is cached in symbols[i].
Just handle an archive using the --start-lib code path. We can therefore remove
ArchiveFile and LazyArchive. For many projects, archive member extraction ratio
is high and it is a net performance win. Linking a Release build of clang is
1.01x as fast.
Note: --start-lib scans symbols in the same order that llvm-ar adds them to the
index, so in the common case the semantics should be identical. If the archive
symbol table was created in a different order, or is incomplete, this strategy
may have different semantics. Such cases are considered user error.
The `is neither ET_REL nor LLVM bitcode` error is changed to a warning.
Previously an archive may have such members without a diagnostic. Using a
warning prevents breakage.
* For some tests, the diagnostics get improved where we did not consider
the archive member name: `b.a:` => `b.a(b.o):`.
* `no-obj.s`: the link is now allowed, matching GNU ld
* `archive-no-index.s`: the `is neither ET_REL nor LLVM bitcode` diagnostic is
demoted to a warning.
* `incompatible.s`: even when an archive is unextracted, we may report an
"incompatible with" error.
---
I recently decreased sizeof(SymbolUnion) by 8 and decreased memory usage quite a
bit, so retaining `symbols` for un-extracted archive members should not cause a
memory usage problem.
Reviewed By: peter.smith
Differential Revision: https://reviews.llvm.org/D119074
Casting between scalable vectors and fixed-length vectors doesn't make
sense. If one of the operands is scalable, the other has to be scalable
to be able to guarantee they have the same shape at runtime.
Differential Revision: https://reviews.llvm.org/D119568
Minor comment updates and use getVoidPtr helper instead of
builiding `i8*` type manually in codegen.
Differential Revision: https://reviews.llvm.org/D119828
vp.select|merge both select lanes based on a condition mask. Unlike
other VP intrinsics the lanes are defined where the condition mask is
false. Hence, the condition mask in vp.select|mask is not a mask in the
sense of VP intrinsics. By doing not treating the condition mask
specially, vp.select becomes the canonical VP translation of the select
instruction.
Reviewed By: frasercrmck
Differential Revision: https://reviews.llvm.org/D118981
Simplify the logic when the exponent difference is at least MantissaLength + 2, while still maintaining correct rounding for all rounding modes.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D119843
This is a more generic version of D119110 that uses MaskedValueIsZero
to do the matching and SimplifyDemandedBits to remove any unneeded
AND instructions.
Tests were taken from D119110.
Reviewed By: Chenbing.Zheng
Differential Revision: https://reviews.llvm.org/D119622
Parsing errors aren't handled earlier in all cases. A simple
example is llc -mtriple=riscv64 -mattr=+zve32f. If F or Finx is
not also specified, this will hit a parse error.
Use a fatal_error so that the error is conveyed to the user.
Previously, Transformer would invoke the consumer once per file modified per
match, in addition to any errors encountered. The consumer is not aware of which
AtomicChanges come from any particular match. It is unclear which sets of edits
may be related or whether an error invalidates any previously emitted changes.
Modify the signature of the consumer to accept a set of changes. This keeps
related changes (i.e. all edits from a single match) together, and clarifies
that errors don't produce partial changes.
Reviewed By: ymandel
Differential Revision: https://reviews.llvm.org/D119745
This should work now that we are using a matching libunwind.dylib when
we run the tests in back-deployment scenarios. The only restriction we
have now is to run on macOS x86_64, since that's what the old dylibs
were compiled for. This should allow us to move to newer AppleClangs
in the CI.
As a fly-by, fix missing availability annotations on optional's
monadic operations.
Differential Revision: https://reviews.llvm.org/D119840
As suggested in D117966.
These conditional noexcepts are *permitted* by the Standard (as long
as there were no mistakes in them, I guess); but not *mandated*.
The Standard doesn't put any noexcept-specifications on these member functions.
The same logic would apply to `transform_view::iterator::operator*`
and `transform_view::iterator::operator[]`, but the Standard mandates
conditional noexcept on `iter_move(transform_view::iterator)`, and
I think it doesn't make much sense to say "moving from this iterator
is conditionally noexcept but not-moving from it is noexcept(false),"
so I'm leaving transform_view alone for now.
Differential Revision: https://reviews.llvm.org/D119374
A more general enhancement needs to add tests and make sure
that intrinsics that return structs are correct. There are also
target-specific intrinsics, and I'm not sure what behavior is
expected for those.
A more general enhancement needs to add tests and make sure
that intrinsics that return structs are correct. There are also
target-specific intrinsics, and I'm not sure what behavior is
expected for those.
In src/, most files can use `constinit` directly because they're always
compiled with C++20. But some files, like "libcxxabi/src/fallback_malloc.cpp",
can't, because they're `#include`d directly from test cases in libcxxabi/test/
and therefore must (currently) compile as C++03. We might consider refactoring
those offending tests, or at least marking them `UNSUPPORTED: c++03`.
Differential Revision: https://reviews.llvm.org/D119264
The logic here is that we are disabling *only* things in `std::ranges::`.
Everything in `std::` is permitted, including `default_sentinel`, `contiguous_iterator`,
`common_iterator`, `projected`, `swappable`, and so on. Then, we include
anything from `std::ranges::` that is required in order to make those things
work: `ranges::swap`, `ranges::swap_ranges`, `input_range`, `ranges::begin`,
`ranges::iter_move`, and so on. But then that's all. Everything else (including
notably all of the "views" and the `std::views` namespace itself) is still
locked up behind `_LIBCPP_HAS_NO_INCOMPLETE_RANGES`.
Differential Revision: https://reviews.llvm.org/D118736
`kEmitAccessorPrefix_Raw ` is being removed, and so updating the
accessors to `kEmitAccessorPrefix_Prefixed`.
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D119812
This patch adds lowering of ranked array as function return.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D119835
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch updates the handling of vectors in getPreferredVectorAction():
For single-element and scalable vectors, fall back to default vector legalization
handling. For vNi1 vectors, add handling to either split or promote them in
order to prevent the production of wide v256i1/v512i1 types.
The following assertion is fixed by this patch, as we ended up producing the
wide vector types (that are used for MMA) in the backend prior to this fix.
```
Assertion failed: VT.getSizeInBits() == Operand.getValueSizeInBits() &&
"Cannot BITCAST between types of different sizes!"
```
Differential Revision: https://reviews.llvm.org/D119521
Summary:
Added a new option "-X" to specify, which type of object file should be examine.
For example:
1. "llvm-nm -X64 archive.a" only deal with the 64bit object files in the archive.a ,ignore the all 32bit object files in the archive.a
2. "llvm-nm -X32 xcoffobj32.o xcoffobj64.o " only deal with the 32bit object file "xcoffobj32.o" , 64bit object file "xcoffobj64.o" will be ignored
Reviewers: James Henderson,Fangrui Song
Differential Revision: https://reviews.llvm.org/D118193
A significant number of our tests in C accidentally use functions
without prototypes. This patch converts the function signatures to have
a prototype for the situations where the test is not specific to K&R C
declarations. e.g.,
void func();
becomes
void func(void);
This is the tenth batch of tests being updated (there are a
significant number of other tests left to be updated).
The test would trigger -Wtautological-compare. I think that the little
we gain from comparing addresses isn't worth the added complexity to
work around the warning.
Extend the existing split where we already do this for v32i16/v64i8
We can end up trying to use PCMPEQ/GT if the result needs to be sign-extended (typically due to the DAGCombiner::foldSextSetcc fold).
Fixes#53842
Krzysztof Drewniak