- Dec 07, 2021
-
-
Jonas Paulsson authored
Memset with a constant length was implemented with a single store followed by a series of MVC:s. This patch changes this so that one store of the byte is emitted for each MVC, which avoids data dependencies between the MVCs. An MVI/STC + MVC(len-1) is done for each block. In addition, memset with a variable length is now also handled without a libcall. Since the byte is first stored and then MVC is used from that address, a length of two must now be subtracted instead of one for the loop and EXRL. This requires an extra check for the one-byte case, which is handled in a special block with just a single MVI/STC (like GCC). Review: Ulrich Weigand Differential Revision: https://reviews.llvm.org/D112004
-
Martin Probst authored
ES2021 allows numeric literals using `_` as a separator. This already works, but had no test. Differential Revision: https://reviews.llvm.org/D115147
-
Noah Shutty authored
This adds a Debuginfod client library which queries servers specified by the `DEBUGINFOD_URLS` environment variable for the debuginfo, executable, or a specified source file associated with a given build id. Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D112758
-
Aaron Ballman authored
WG14 adopted the _ExtInt feature from Clang for C23, but renamed the type to be _BitInt. This patch does the vast majority of the work to rename _ExtInt to _BitInt, which accounts for most of its size. The new type is exposed in older C modes and all C++ modes as a conforming extension. However, there are functional changes worth calling out: * Deprecates _ExtInt with a fix-it to help users migrate to _BitInt. * Updates the mangling for the type. * Updates the documentation and adds a release note to warn users what is going on. * Adds new diagnostics for use of _BitInt to call out when it's used as a Clang extension or as a pre-C23 compatibility concern. * Adds new tests for the new diagnostic behaviors. I want to call out the ABI break specifically. We do not believe that this break will cause a significant imposition for early adopters of the feature, and so this is being done as a full break. If it turns out there are critical uses where recompilation is not an o...
-
Balazs Benics authored
Previously, the `SValBuilder` could not encounter expressions of the following kind: NonLoc OP Loc Loc OP NonLoc Where the `Op` is other than `BO_Add`. As of now, due to the smarter simplification and the fixedpoint iteration, it turns out we can. It can happen if the `Loc` was perfectly constrained to a concrete value (`nonloc::ConcreteInt`), thus the simplifier can do constant-folding in these cases as well. Unfortunately, this could cause assertion failures, since we assumed that the operator must be `BO_Add`, causing a crash. --- In the patch, I decided to preserve the original behavior (aka. swap the operands (if the operator is commutative), but if the `RHS` was a `loc::ConcreteInt` call `evalBinOpNN()`. I think this interpretation of the arithmetic expression is closer to reality. I also tried naively introducing a separate handler for `loc::ConcreteInt` RHS, before doing handling the more generic `Loc` RHS case. However, it broke the `zoo1backwards()` test in the `nullptr.cpp` file. This highlighted for me the importance to preserve the original behavior for the `BO_Add` at least. PS: Sorry for introducing yet another branch into this `evalBinOpXX` madness. I've got a couple of ideas about refactoring these. We'll see if I can get to it. The test file demonstrates the issue and makes sure nothing similar happens. The `no-crash` annotated lines show, where we crashed before applying this patch. Reviewed By: martong Differential Revision: https://reviews.llvm.org/D115149
-
James Farrell authored
Revert "Use VersionTuple for parsing versions in Triple, fixing issues that caused the original change to be reverted. This makes it possible to distinguish between "16" and "16.0" after parsing, which previously was not possible." This reverts commit 50324670.
-
Jonas Devlieghere authored
Revert "[clang][DebugInfo] Allow function-local statics and types to be scoped within a lexical block" This reverts commit e403f4fd because it breaks TestSetData.py on GreenDragon: https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/39089/
-
Craig Topper authored
The immediate size check on StepNumerator did not take into account that vmul.vi does not exist. It also did not account for power of 2 constants that can be done with vshl.vi. This patch fixes this by moving the conversion from mul to shift further up. Then we can consider the immediates separately for MUL vs SHL. For MUL I've allowed simm12 which requires a single addi before a vmul.vx. For SHL I've allowed any uimm5 which works with vshl.vi. We could relax these further in the future. This is a starting point that allows us to emit the same number of instructions we were already using for smaller numerators. Reviewed By: frasercrmck Differential Revision: https://reviews.llvm.org/D115081
-
Joseph Huber authored
Reduction functions were guarded before which was wrong, these are SPMD compatible. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D115159
-
Joseph Huber authored
Before SPMDzation it was sufficient to add an incompatible instruction to the SPMDCompatibilityTracker. However, now adding instructions means they need guarding. As calls cannot be guarded in general we need to explicitly prevent SPMD mode. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D115158
-
Evgeny Mandrikov authored
Without this patch when using CMAKE_CXX_STANDARD=20 and MSVC 19.30.30705.0 compilation of unit tests fails with llvm\utils\unittest\googlemock\include\gmock/gmock-actions.h(828): error C2039: 'result_of': is not a member of 'std' Patch is taken from Google Test: https://github.com/google/googletest/commit/61f010d703b32de9bfb20ab90ece38ab2f25977f Do not use std::result_of as it was removed in C++20. Differential Revision: https://reviews.llvm.org/D115163
-
LLVM GN Syncbot authored
-
spupyrev authored
A new basic block ordering improving existing MachineBlockPlacement. The algorithm tries to find a layout of nodes (basic blocks) of a given CFG optimizing jump locality and thus processor I-cache utilization. This is achieved via increasing the number of fall-through jumps and co-locating frequently executed nodes together. The name follows the underlying optimization problem, Extended-TSP, which is a generalization of classical (maximum) Traveling Salesmen Problem. The algorithm is a greedy heuristic that works with chains (ordered lists) of basic blocks. Initially all chains are isolated basic blocks. On every iteration, we pick a pair of chains whose merging yields the biggest increase in the ExtTSP value, which models how i-cache "friendly" a specific chain is. A pair of chains giving the maximum gain is merged into a new chain. The procedure stops when there is only one chain left, or when merging does not increase ExtTSP. In the latter case, the remaining chains are sorted by density in decreasing order. An important aspect is the way two chains are merged. Unlike earlier algorithms (e.g., based on the approach of Pettis-Hansen), two chains, X and Y, are first split into three, X1, X2, and Y. Then we consider all possible ways of gluing the three chains (e.g., X1YX2, X1X2Y, X2X1Y, X2YX1, YX1X2, YX2X1) and choose the one producing the largest score. This improves the quality of the final result (the search space is larger) while keeping the implementation sufficiently fast. Differential Revision: https://reviews.llvm.org/D113424
-
Jon Chesterfield authored
Reverts D114965 as the compiler backend appears to be working again Reviewed By: jhuber6 Differential Revision: https://reviews.llvm.org/D115157
-
Peter Waller authored
f526c600 had a concern raised because of an invalid typesize request on a scalable vector, which this patch addresses. Prevent shouldReduceLoadWidth from attempting to query the bit size, and add a regression test in sve-extract-fixed-vector.ll. Differential Revision: https://reviews.llvm.org/D115156
-
Kazu Hirata authored
-
Jon Chesterfield authored
Analogous to the controls on building device runtimes Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D115148
-
Jon Chesterfield authored
Minor fix to the lit.cfg. Currently, nvptx runs the tests twice on the new runtime. Soon, amdgpu will run them on the new runtime as well as the old. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D115150
-
Bardia Mahjour authored
Added TTI queries for the cost of a VP Memory operation, and added Opcode, DataType and Alignment to the hasActiveVectorLength() interface. Reviewed By: Roland Froese Differential Revision: https://reviews.llvm.org/D109416
-
Arthur O'Dwyer authored
Clang trunk rejects the new test case, but this is a Clang bug (PR47414, 47509, 50864, 44833). ``` In module 'std' imported from /Users/aodwyer/llvm-project/libcxx/test/std/ranges/range.adaptors/range.transform/general.pass.cpp:17: /Users/aodwyer/llvm-project/build2/include/c++/v1/__ranges/transform_view.h:85:44: error: constraints not satisfied for alias template 'range_reference_t' [with _Rp = const NonConstView] regular_invocable<const _Fn&, range_reference_t<const _View>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /Users/aodwyer/llvm-project/build2/include/c++/v1/__ranges/transform_view.h:416:25: note: in instantiation of template class 'std::ranges::transform_view<NonConstView, (lambda at /Users/aodwyer/llvm-project/libcxx/test/std/ranges/range.adaptors/range.transform/general.pass.cpp:73:71)>' requested here -> decltype( transform_view(_VSTD::forward<_Range>(__range), _VSTD::forward<_Fn>(__f))) ^ ``` We can work around this by adding a layer of indirection: put the problematic constraint into a named concept and Clang becomes more amenable to SFINAE'ing instead of hard-erroring. Drive-by simplify `range.transform/general.pass.cpp` to make it clearer what it's actually testing in this area. Differential Revision: https://reviews.llvm.org/D115116
-
- Dec 06, 2021
-
-
Simon Moll authored
Reverted until all Toolchains are fixed for the new behavior. This reverts commit 34a43f21.
-
Jon Chesterfield authored
Reviewed By: pdhaliwal Differential Revision: https://reviews.llvm.org/D114891
-
Ties Stuij authored
When committing the PACBTI-M frontend support patch (https://reviews.llvm.org/D112421), the tests in arm-invalid-branch-protection.c were failing on certain test setups, so it was removed to make the llvm test suite pass. The fix is to require arm-registered-target. This patch is part of a series that adds support for the PACBTI-M extension of the Armv8.1-M architecture, as detailed here: https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/armv8-1-m-pointer-authentication-and-branch-target-identification-extension The PACBTI-M specification can be found in the Armv8-M Architecture Reference Manual: https://developer.arm.com/documentation/ddi0553/latest Reviewed By: erichkeane Differential Revision: https://reviews.llvm.org/D115141
-
Nikita Popov authored
As pointed out in https://reviews.llvm.org/D114936#3173327, unit tests were still using deprecated C APIs.
-
James Farrell authored
Use VersionTuple for parsing versions in Triple, fixing issues that caused the original change to be reverted. This makes it possible to distinguish between "16" and "16.0" after parsing, which previously was not possible. This reverts commit 40d5eeac. Differential Revision: https://reviews.llvm.org/D114885
-
Chuanqi Xu authored
Reviewed by: StephenTozer Differential Revision: https://reviews.llvm.org/D115139
-
Valentin Clement authored
This patch adds the conversion pattern for the fircg.ext_array_coor operation. It applies the address arithmetic on a dynamically shaped, shifted and/or sliced array. This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D113968 Co-authored-by:
Eric Schweitz <eschweitz@nvidia.com> Co-authored-by:
Jean Perier <jperier@nvidia.com>
-
Jake Egan authored
This patch adds `emitXCOFFSymbolLinkageWithVisibility` to MCNullStreamer to fix llvm_unreachable getting reached when using option `-filetype=null` on AIX. Reviewed By: DiggerLin Differential Revision: https://reviews.llvm.org/D114876
-
Pavel Labath authored
Lldb uses a pty to read/write to the standard input and output of the debugged process. For host processes this would be automatically set up by Target::FinalizeFileActions. The Qemu platform is in a unique position of not really being a host platform, but not being remote either. It reports IsHost() = false, but it is sufficiently host-like that we can use the usual pty mechanism. This patch adds the necessary glue code to enable pty redirection. It includes a small refactor of Target::FinalizeFileActions and ProcessLaunchInfo::SetUpPtyRedirection to reduce the amount of boilerplate that would need to be copied. I will note that qemu is not able to separate output from the emulated program from the output of the emulator itself, so the two will arrive intertwined. Normally this should not be a problem since qemu should not produce any output during regular operation, but some output can slip through in case of errors. This situation should be pretty obvious (...
-
Pavel Labath authored
-
Pavel Labath authored
This is the lua equivalent of 9a14adea.
-
Michał Górny authored
Recognize FreeBSD vmcores (kernel core dumps) through OS ABI = 0xFF + ELF version = 0, and do not process them via the elf-core plugin. While these files use ELF as a container format, they contain raw memory dump rather than proper VM segments and therefore are not usable to the elf-core plugin. Differential Revision: https://reviews.llvm.org/D114967
-
Jon Chesterfield authored
These tests tend to hang or crash on hardware that doesn't support USM. Disabling them helps diagnose other issues. To safely enable we require a means of testing whether USM is expected to work. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D115144
-
Florian Hahn authored
-
Alex Zinenko authored
Conversion of LLVM named structs leads to them being renamed since we cannot modify the body of the struct type once it is set. Previously, this applied to all named struct types, even if their element types were not affected by the conversion. Make this behvaior only applicable when element types are changed. This requires making the LLVM dialect type-compatibility check recursively look at the element types (arguably, it should have been doing than since the moment the LLVM dialect type system stopped being closed). In addition, have a more lax check for outer types only to avoid repeated check when necessary (e.g., parser, verifiers that are going to also look at the inner type). Reviewed By: wsmoses Differential Revision: https://reviews.llvm.org/D115037
-
Simon Moll authored
Before, the CLANG_DEFAULT_LINKER cmake option was a global override for the linker that shall be used on all toolchains. The linker binary specified that way may not be available on toolchains with custom linkers. Eg, the only linker for VE is named 'nld' - any other linker invalidates the toolchain. This patch removes the hard override and instead lets the generic toolchain implementation default to CLANG_DEFAULT_LINKER. Toolchains can now deviate with a custom linker name or deliberatly default to CLANG_DEFAULT_LINKER. Reviewed By: MaskRay, phosek Differential Revision: https://reviews.llvm.org/D115045
-
Dmitry Vyukov authored
Reviewed By: melver Differential Revision: https://reviews.llvm.org/D115142
-
Sander de Smalen authored
If the condition of a select is a compare, pass its predicate to TTI::getCmpSelInstrCost to get a more accurate cost value instead of passing BAD_ICMP_PREDICATE. I noticed that the commit message from D90070 had a comment about the vectorized select predicate possibly being composed of other compares with different predicate values, but I wasn't able to construct an example where this was an actual issue. If this is an issue, I guess we could add another check that the block isn't predicated for any reason. Reviewed By: dmgreen, fhahn Differential Revision: https://reviews.llvm.org/D114646
-
Dmitri Gribenko authored
This documentation supports the dataflow analysis framework (see "[RFC] A dataflow analysis framework for Clang AST" on cfe-dev). Since the implementation of the framework has not been committed yet, right now the doc describes dataflow analysis in general. Since this is the first markdown document in clang/docs, I added support for Markdown to clang/docs/conf.py in the same way as it is done in llvm/docs. Reviewed By: xazax.hun Differential Revision: https://reviews.llvm.org/D114231
-
Kazushi (Jam) Marukawa authored
Support VE specific data directives, .word/.long/.llong, in MC layer. Reviewed By: simoll Differential Revision: https://reviews.llvm.org/D115120
-