| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
We don't know which test suites are going to be included by runtimes
builds so we cannot include those before running the sub-build, but
that's not possible during the LLVM build configuration. We instead use
a response file that's populated by the runtimes build as a level of
indirection.
This addresses the issue described in:
https://discourse.llvm.org/t/cmake-regeneration-is-broken/62788
Differential Revision: https://reviews.llvm.org/D132438
|
|
Link: https://github.com/llvm/llvm-project/issues/58048
Reviewed By: ftynse, Mogball
Differential Revision: https://reviews.llvm.org/D134850
|
|
clang-aarch64-sve-vla crashes in msan
clang-s390x-linux-lnt fails to compile libcxx
This reverts commit 14b2b67cd7d5e439c4bc5c8051f68a5fbb683480.
|
|
These are semantically two different stages, but were entwined in the
old implementation. Now cost computation does not do legality checks,
and they all are done beforehead.
|
|
Split out a major peice of this method to make code more readable.
|
|
Improve the logic in FindZstd to support finding both shared and static
variants of the zstd library simultaneously. Otherwise, if the shared
library is installed, zstd::libzstd_static is not declared at all
and CMake fails if LLVM_USE_STATIC_ZSTD is used.
Differential Revision: https://reviews.llvm.org/D135457
|
|
CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION
Instead of setting libclang.so's SOVERSION to CLANG_MAJOR_VERSION
when CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION is enabled, do not override
it and let LLVM set the correct SOVERSION. This fixes libclang.so
missing LLVM_VERSION_SUFFIX, and harmonizes the SOVERSION with other
shared libraries.
Differential Revision: https://reviews.llvm.org/D135701
|
|
The specific case I hit this was when lowering an `async.execute` that's
not inside a `func.func` op, e.g.:
```
llvm.func @foo() {
%token = async.execute {
async.yield
}
llvm.return
}
```
Reviewed By: bondhugula
Differential Revision: https://reviews.llvm.org/D135742
|
|
TileUsingInterface.cpp (NFC)
|
|
TileUsingInterface.cpp (NFC)
|
|
|
|
COMPILER_RT_LIBCXX_PATH is required for msan unittests.
|
|
`_cmd` parameter.
This fixes a bug from https://reviews.llvm.org/D131424 that removed the implicit `_cmd` parameter as an argument to `objc_direct` method implementations. In many cases the generated getter/setter will call `objc_getProperty` or `objc_setProperty`, both of which require the selector of the getter/setter; since `_cmd` didn't automatically have backing storage, attempting to load the address asserted.
For direct property generated getters/setters, this now passes an undefined/uninitialized/poison value as the `_cmd` argument to `objc_getProperty`/`objc_setProperty`. Prior to removing the `_cmd` argument from the ABI of direct methods, it was left uninitialized/undefined; although references within hand-implemented methods would load the selector in the method prologue, generated getters/setters never did and just forwarded the undefined value that was passed as the argument.
This change keeps the generated code mostly similar to before, passing an uninitialized/undefined/poison value; for setters, the value argument may be moved to another register.
Added a test that triggers the assert prior to the implementation code.
Differential Revision: https://reviews.llvm.org/D135091
|
|
We already do this for personality pointers referenced from compact
unwind entries; this patch extends that behavior to personalities
referenced via EH frames as well.
This reduces the number of distinct personalities we need in the final
binary, and helps us avoid hitting the "too many personalities" error.
I renamed `UnwindInfoSection::prepareRelocations()` to simply `prepare`
since we now do some non-reloc-specific stuff within.
Fixes #58277.
Reviewed By: #lld-macho, oontvoo
Differential Revision: https://reviews.llvm.org/D135728
|
|
Fix the issue: #57684
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D135512
|
|
The patch selects VSELECT/VP_MERGE_VL which uses fmadd/fnmsub as true operand
and the adden of the fmadd/fnmsub as false operand.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D135330
|
|
BufferizableOpInterfaceImpl.cpp (NFC)
|
|
|
|
the policy operand.
If the source is implicit_def, the register allocator won't have
any constraint on what register it picks for the destination. This
doesn't give the user much control of what register is being used.
So in my mind that means the only reason to honor the policy operand
is to control what policy is used in vsetvli to maybe avoid a vtype
change. Given the other optimizations we do on the policy field, I
don't think allowing the user this control is reliable.
Therefore, I think we should use agnostic policies if the source is
undef.
This should give better performance on some CPUs for VP intrinsics where
there is no merge operand and the backend adds IMPLICIT_DEF to the instruction.
Differential Revision: https://reviews.llvm.org/D135396
|
|
BW-1), Y))"
This reverts commit 0148df8157f05ecf3b1064508e6f012aefb87dad.
Getting a lit test failures on AMDGPU but I can't reproduce it so far.
Reverting to investigate.
|
|
This isn't bound to any instruction. From the section comment it
was for single-width F-to-F conversions, but those don't exist.
|
|
Reviewed By: aeubanks
Differential Revision: https://reviews.llvm.org/D135524
|
|
Reviewed By: aartbik, wrengr
Differential Revision: https://reviews.llvm.org/D135480
|
|
(sra X, BW-1) is either 0 or -1. So the multiply is a conditional
negate of Y.
This pattern shows up when type legalizing wide multiplies involving
a sign extended value.
Fixes PR57549.
Reviewed By: RKSimon
Differential Revision: https://reviews.llvm.org/D133399
|
|
This provides a workaround for a small difference in ld64 behavior where
ld64 ignores invalid LC_LINKER_OPTIONS unless the link fails. Instead of
fully adopting that behavior, this provides an escape hatch by allowing
users to specify `--ignore-auto-link-option` passing the invalid library
or framework name
Fixes https://github.com/llvm/llvm-project/issues/56939
Differential Revision: https://reviews.llvm.org/D135530
|
|
The dependency scanner needs to report the module map file describing the module whose implementation is being compiled (see D134222). However, calling `Preprocessor::getCurrentModuleImplementation()` in the scanner might cause a diagnostic during module map parsing and emitting a diagnostic without being "in" a source file is illegal (e.g. in `TextDiagnosticPrinter`). This patch ensures the module map parse is triggered while the compiler is still "in" a source file, avoiding the failure case.
Reviewed By: Bigcheese
Differential Revision: https://reviews.llvm.org/D135637
|
|
Codegen options are typically unused by modules. Reset some of them to increase sharing between TUs with different flags.
Reviewed By: Bigcheese
Differential Revision: https://reviews.llvm.org/D135720
|
|
The Offloading toolchain currently has two methods for construction the
requires actions. The "new" driver and the old `OffloadActionBuilder`.
Using either one is mutually exclusive, so we should not initialize this
when using the new driver. This was causing some error messages to be
printed multiple times because we were checking them in both the old and
the new driver.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D135715
|
|
lldb-vscode is hard-coded to source .lldbinit file which causes some tests to
fail on my machine.
This patch adds a new option to control this:
1. vscode.py and lldb-vscode tests will not source .lldbinit by default
2. lldb-vscode will source .lldbinit in production if not specified otherwise
Differential Revision: https://reviews.llvm.org/D135620
|
|
We support KnownBits for vectors, so we can enable these.
https://godbolt.org/z/r9a9W4Gj1
Differential Revision: https://reviews.llvm.org/D135719
|
|
Differential Revision: https://reviews.llvm.org/D135611
|
|
available_externally
For a local linkage GlobalObject in a non-prevailing COMDAT, it remains defined while its
leader has been made available_externally. This violates the COMDAT rule that
its members must be retained or discarded as a unit.
To fix this, update the regular LTO change D34803 to track local linkage
GlobalValues, and port the code to ThinLTO (GlobalAliases are not handled.)
This fixes two problems.
(a) `__cxx_global_var_init` in a non-prevailing COMDAT group used to
linger around (unreferenced, hence benign), and is now correctly discarded.
```
int foo();
inline int v = foo();
```
(b) Fix https://github.com/llvm/llvm-project/issues/58215:
as a size optimization, we place private `__profd_` in a COMDAT with a
`__profc_` key. When FuncImport.cpp makes `__profc_` available_externally due to
a non-prevailing COMDAT, `__profd_` incorrectly remains private. This change
makes the `__profd_` available_externally.
```
cat > c.h <<'eof'
extern void bar();
inline __attribute__((noinline)) void foo() {}
eof
cat > m1.cc <<'eof'
int main() {
bar();
foo();
}
eof
cat > m2.cc <<'eof'
__attribute__((noinline)) void bar() {
foo();
}
eof
clang -O2 -fprofile-generate=./t m1.cc m2.cc -flto -fuse-ld=lld -o t_gen
rm -fr t && ./t_gen && llvm-profdata show -function=foo t/default_*.profraw
clang -O2 -fprofile-generate=./t m1.cc m2.cc -flto=thin -fuse-ld=lld -o t_gen
rm -fr t && ./t_gen && llvm-profdata show -function=foo t/default_*.profraw
```
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D135427
|
|
Reviewed By: aartbik
Differential Revision: https://reviews.llvm.org/D135692
|
|
.addrsig_sym forces registering the symbol regardless whether it is otherwise
registered. This creates an undefined symbol which is inconvenient/undesired:
* `extern int x; void f() { (void)x; }` has inconsistent behavior whether `x` is emitted as an undefined symbol.
`-O0 -faddrsig` makes `x` undefined while other -O levels and -fno-addrsig eliminate the symbol.
* In ThinLTO, after a non-prevailing linkonce_odr definition is converted to available_externally, and then a declaration,
the addrsig code emits a symbol while the symbol is otherwise unseen.
D135427 fixed a bug that a non-prevailing `__cxx_global_var_init` was
incorrectly retained. However, the IR declaration causes an undesired
`.addrsig_sym __cxx_global_var_init`. This can be addressed in a way similar
to D101512 (`isTransitiveUsedByMetadataOnly`) but the increased
`OutStreamer->emitAddrsigSym(getSymbol(&GV));` complexity makes me nervous.
Just ignoring unregistered symbols circumvents the problem.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D135642
|
|
The "mlir_xxx_utils" naming scheme is reserved/intended for shared libraries, whereas this library must be static due to issues of linking DLLs on Windows. So we rename the library to avoid any potential confusion. In addition we also rename the ExecutionEngine/SparseTensorUtils.{h,cpp} files to match the new library name.
Reviewed By: aartbik, stella.stamenova
Differential Revision: https://reviews.llvm.org/D135613
|
|
And remove the legacy opt-specific pass.
Reviewed By: asbirlea
Differential Revision: https://reviews.llvm.org/D135487
|
|
Move a few supporting routines for generating function calls to CodegenUtils so
that they can be used by the codegen path for sparse tensor file input and
output.
Reviewed By: aartbik
Differential Revision: https://reviews.llvm.org/D135691
|
|
Differential Revision: https://reviews.llvm.org/D135675
|
|
The LIT test cases were migrated with the script provided by
Nikita Popov.
No manual changes were made. Committed without review since
no functional changes, after consultation with uweigand.
|
|
This differential comprises three related changes: (1) it gives SparseTensorCOO standard C++-style iterators; (2) it removes the old iterator stuff from SparseTensorCOO; and (3) it introduces SparseTensorIterator which behaves like the old SparseTensorCOO iterator stuff used to.
The SparseTensorIterator class is needed because the MLIR codegen cannot easily use the C++-style iterators (hence why SparseTensorCOO had the old iterator stuff). Distinguishing SparseTensorIterator from SparseTensorCOO also helps improve API hygiene since these two classes are used for distinct purposes. And having SparseTensorIterator as its own class enables changing the underlying implementation in the future, without needing to worry about updating all the codegen tests etc.
Reviewed By: aartbik
Differential Revision: https://reviews.llvm.org/D135485
|
|
inline
Performing a load before calling __cxa_guard_acquire is supposed to be
an optimization, but it isn't much of one if we're just going to emit a
call to __atomic_load_1 instead. Instead, just skip the load, and
let __cxa_guard_acquire do whatever it wants.
(In practice, on such targets, the C++ library is just built with
threading turned off, so the result isn't actually threadsafe, but
there's not really anything clang can do about that.)
The alternative here is that we try to define some ABI for threadsafe
init that allows the speculative load without full atomics. Almost any
target without full atomics has a load that's s "atomic enough" for this
purpose. But it's not clear how we emit an "atomic enough" load in LLVM
IR, and there isn't any ABI document we can refer to.
Or I guess we could turn off -fthreadsafe-statics by default on
Cortex-M0, but that seems like it would be surprising.
Fixes https://github.com/llvm/llvm-project/issues/58184
Differential Revision: https://reviews.llvm.org/D135628
|
|
`-Wunused-variable` diagnostic
Commit `371883f46dc23f8464cbf578e2d12a4f92e61917` caused a noticeable compile-time regression (about 0.4% geomean at -O0):
http://llvm-compile-time-tracker.com/compare.php?from=92233159035d1b50face95d886901cf99035bd99&to=371883f46dc23f8464cbf578e2d12a4f92e61917&stat=instructions
To address this switch `Scope::DeclSetTy` back to a `SmallPtrSet` and change `Sema::ActOnPopScope` to explicitly order the diagnostics that this function emits.
Differential Revision: https://reviews.llvm.org/D135490
|
|
Make sure we propagate the value for `IsArrow` to
`RebuildExtVectorElementExpr` in order to be able to handle correctly
vector component accesses where the base value is a pointer.
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D131698
|
|
|
|
|
|
We don't use the "instantiate" word for the macro expansion in LLVM,
see c9c8419c383d0b53c40973f7587003ef45daf481.
|
|
Libcxx gdb pretty printers were disabled due to an old version
of gdb in the release testing. This reenables them, and fixes
various bit rot issues from not running them.
|
|
This adds infrastructural pieces for an analysis to compute the DXIL
shader flags. In this state the analysis can compute two fairly
straightforward feature flags for use of double-precision floating
point values and the DX 11.1 extended double support.
This patch does conflict with D135190, conflicts will be resolved prior
to merging.
Reviewed By: python3kgae
Differential Revision: https://reviews.llvm.org/D135393
# Conflicts:
# llvm/lib/Target/DirectX/CMakeLists.txt
# llvm/lib/Target/DirectX/DirectXTargetMachine.cpp
|
|
|
|
and libunwind
We already had the ability to do that for libc++.dylib, so this only adds
consistency for all the runtime libraries. This should allow working around
difficulties on AIX as described in https://llvm.org/D134221.
Differential Revision: https://reviews.llvm.org/D135669
|
