| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
**KEY POINTS**
- MVP workflow to automatically lint C++ files, located **only** in
`clang-tools-extra/clang-tidy`. It's chosen this way as
`clang-tools-extra/clang-tidy` is almost 100% `clang-tidy` complaint,
thus we would automatically enforce a [high quality standard for
clang-tidy source
code](https://discourse.llvm.org/t/rfc-create-hardened-clang-tidy-config-for-clang-tidy-directory/87247).
(https://github.com/llvm/llvm-project/pull/147793)
- Implementation is very similar to code-format job, but without the
ability to run `code-lint-helper.py` locally.
**FOUND ISSUES** + open questions
- Speed: it takes ~ 1m40sec to download and unpack `clang-tidy` plus
additional ~4 mins to configure and CodeGen targets. I see that
`premerge.yaml` runs on special `llvm-premerge-linux-runners` runners
which can use `sccache` for speed. Can we use the same runners for this
job? Exact timings can be found
[here](https://github.com/llvm/llvm-project/actions/runs/17135749067/job/48611150680?pr=154223).
**TO DO**
- Place common components from `code-lint-helper.py` and
`code-format-helper.py` into a separate file and reuse it in both CI's.
- Compute CodeGen targets based on `projects_to_build`, for now
`clang-tablegen-targets` is hardcoded for `clang-tools-extra/`.
- Automatically generate and upload `.yaml` for
`clang-apply-replacements`
- Create an RFC with a plan how to enable `clang-tidy` in other projects
so that Maintainers of LLVM components could choose if they want
`clang-tidy` or not.
- Add more linters like `pylint`, `ruff` in the future.
|
|
|
|
Remove dce,instcombine from run lines from test to make it easier to
check the output generated by LV.
|
|
readability-container-contains (#157243)
Fix #109327. Small parts taken from #110351.
Removed the type checking between `contains` and `count`/`find`
arguments for simplicity. Because of overloads, this type-checking is
tricky. The same strategy is used in `modernize-use-starts-ends-with`.
Co-authored-by: dl8sd11 <gcchen@google.com>
|
|
This a reland of https://github.com/llvm/llvm-project/pull/155741 which
was reverted at https://github.com/llvm/llvm-project/pull/157831. This
version is narrower in scope - it only turns on automatic stub
generation for `MLIRPythonExtension.Core._mlir` and **does not do
anything automatically**. Specifically, the only CMake code added to
`AddMLIRPython.cmake` is the `mlir_generate_type_stubs` function which
is then used only in a manual way. The API for
`mlir_generate_type_stubs` is:
```
Arguments:
MODULE_NAME: The fully-qualified name of the extension module (used for importing in python).
DEPENDS_TARGETS: List of targets these type stubs depend on being built; usually corresponding to the
specific extension module (e.g., something like StandalonePythonModules.extension._standaloneDialectsNanobind.dso)
and the core bindings extension module (e.g., something like StandalonePythonModules.extension._mlir.dso).
OUTPUT_DIR: The root output directory to emit the type stubs into.
OUTPUTS: List of expected outputs.
DEPENDS_TARGET_SRC_DEPS: List of cpp sources for extension library (for generating a DEPFILE).
IMPORT_PATHS: List of paths to add to PYTHONPATH for stubgen.
PATTERN_FILE: (Optional) Pattern file (see https://nanobind.readthedocs.io/en/latest/typing.html#pattern-files).
Outputs:
NB_STUBGEN_CUSTOM_TARGET: The target corresponding to generation which other targets can depend on.
```
Downstream users should use `mlir_generate_type_stubs` in coordination
with `declare_mlir_python_sources` to turn on stub generation for their
own downstream dialect extensions and upstream dialect extensions if
they so choose. Standalone example shows an example.
Note, downstream will also need to set
`-DMLIR_PYTHON_PACKAGE_PREFIX=...` correctly for their bindings.
|
|
Add additional tests benefiting from rewriting existing SCEVAddExprs with
guards.
|
|
Follow-up to https://reviews.llvm.org/D57974, which added calls to
Archive::Child::getFullName() to produce strings in errors.
But getFullName() is only valid on thin archives, and should only be
used to open the file the archive points to. For diagnostics, getName()
is better: It works for both thin and non-thin files, and it doesn't
make a very long string for thin files. And we already prepend the name
of the parent archive file anyways.
|
|
Follow-up to https://reviews.llvm.org/D46527
|
|
std::get free function (#122265)
When we generate the debug-info for a `VarDecl` we try to determine
whether it was introduced as part of a structure binding (aka a "holding
var"). If it was then we don't mark it as `artificial`.
The heuristic to determine a holding var uses
`IgnoreUnlessSpelledInSource` to unwrap the `VarDecl` initializer until
we hit a `DeclRefExpr` that refers to a `Decomposition`. For "tuple-like
decompositions", Clang will generate a call to a `template<size_t I> Foo
get(Bar)` function that retrieves the `Ith` element from the tuple-like
structure. If that function is a member function, we get an AST that
looks as follows:
```
VarDecl implicit used z1 'std::tuple_element<0, B>::type &&' cinit
`-ExprWithCleanups <col:10> 'int' xvalue
`-MaterializeTemporaryExpr <col:10> 'int' xvalue extended by Var 0x11d110cf8 'z1' 'std::tuple_element<0, B>::type &&'
`-CXXMemberCallExpr <col:10> 'int'
`-MemberExpr <col:10> '<bound member function type>' .get 0x11d104390
`-ImplicitCastExpr <col:10> 'B' xvalue <NoOp>
`-DeclRefExpr <col:10> 'B' lvalue Decomposition 0x11d1100a8 '' 'B'
```
`IgnoreUnlessSpelledInSource` happily unwraps this down to the
`DeclRefExpr`. However, when the `get` helper is a free function (which
it is for `std::pair` in libc++ for example), then the AST is:
```
VarDecl col:16 implicit used k 'std::tuple_element<0, const std::tuple<int, int>>::type &' cinit
`-CallExpr <col:16> 'const typename tuple_element<0UL, tuple<int, int>>::type':'const int' lvalue adl
|-ImplicitCastExpr <col:16> 'const typename tuple_element<0UL, tuple<int, int>>::type &(*)(const tuple<int, int> &) noexcept' <FunctionToPointerDecay>
| `-DeclRefExpr <col:16> 'const typename tuple_element<0UL, tuple<int, int>>::type &(const tuple<int, int> &) noexcept' lvalue Function 0x1210262d8 'get' 'const typename tuple_element<0UL, tuple<int, int>>::type &(const tuple<int, int> &) noexcept' (FunctionTemplate 0x11d068088 'get')
`-DeclRefExpr <col:16> 'const std::tuple<int, int>' lvalue Decomposition 0x121021518 '' 'const std::tuple<int, int> &'
```
`IgnoreUnlessSpelledInSource` doesn't unwrap this `CallExpr`, so we
incorrectly mark the binding as `artificial` in debug-info.
This patch adjusts `IgnoreUnlessSpelledInSource` so it unwraps implicit
`CallExpr`s. It's almost identical to how we treat implicit constructor
calls (unfortunately the code can't quite be re-used because a
`CXXConstructExpr` is-not a `CallExpr`, and we check `isElidable`, which
doesn't exist for regular function calls. So I added a new
`IgnoreImplicitCallSingleStep`).
Fixes https://github.com/llvm/llvm-project/issues/122028
|
|
'double' to 'float' in shared_math_test.cpp (#159934)
This test fails under `-Werror=implicit-float-conversion` (like in our
pre-merge CI) because `dsqrtl` returns a double
https://github.com/llvm/llvm-project/blob/2b937daa1310f7c17a03a0a4a7abf83149e1dc71/libc/src/__support/math/dsqrtl.h#L18
Fixes https://github.com/llvm/llvm-project/issues/159932
|
|
combine() combines hash values with recursion on variadic parameters.
This patch replaces the recursion with a C++17 fold expression:
(combine_data(length, buffer_ptr, buffer_end, get_hashable_data(args)),
...);
which expands to:
combine_data(length, buffer_ptr, buffer_end, get_hashable_data(a));
combine_data(length, buffer_ptr, buffer_end, get_hashable_data(b));
combine_data(length, buffer_ptr, buffer_end, get_hashable_data(c));
:
A key benefit of this change is the unification of the recursive step
and the base case. The argument processing and finalization logic now
exist as straight-line code within a single function.
combine_data now takes buffer_ptr by reference. This is necessary
because the previous assignment pattern:
buffer_ptr = combine_data(...)
is syntactically incompatible with a fold expression. The new pattern:
(combine_data(...), ...)
discards return values, so combine_data must update buffer_ptr
directly.
For readability, this patch does the bare minimum to use a fold
expression, leaving further cleanups to subsequent patches. For
example, buffer_ptr and buffer_end could become member variables, and
several comments that mention recursion still need updating.
|
|
(#156354)
fixes #156417
When the relocation section is placed before the relocated section and
the relocated section is not defined in the linker script, an error will
occur during the linking process.
**Issue Cause:**
In a.ro, `.rela.text` precedes its relocated `InputSection` `.text`.
`addOrphanSections` doesn't handle this scenario.
When it processes `.rela.text`, in the called `getOutputSectionName`,
`rel->getOutputSection()` is nullptr (input `.text` doesn't yet have a
parent output section), leading to an assertion failure.
**Solution:**
For --emit-relocs and -r, ensure the output section for `.text.foo` is
created before the output section for `.rela.text.foo`.
---------
Co-authored-by: Fangrui Song <i@maskray.me>
|
|
|
|
This patch simplifies dispatchRecalculateHash and dispatchResetHash
with "constexpr if".
This patch does not inline dispatchRecalculateHash and
dispatchResetHash into their respective call sites. Using "constexpr
if" in a non-template context like MDNode::uniquify would still
require the discarded branch to be syntactically valid, causing a
compilation error for node types that do not have
recalculateHash/setHash. Using template functions ensures that the
"constexpr if" is evaluated in a proper template context, allowing the
compiler to fully discard the inactive branch.
|
|
This patch modernizes HasCachedHash.
- "struct SFINAE" is replaced with identically defined SameType.
- The return types Yes and No are replaced with std::true_type and
std::false_type.
My previous attempt (#159510) to clean up HasCachedHash failed on
clang++-18, but this version works with clang++-18.
|
|
This patch moves IsSizeLessThanThresholdT into AdjustedParamTBase, the
sole user of the helper, while switching to a type alias.
Aside from moving the helper closer to where it's used, another
benefit is that we can assume that T is a complete type inside
AdjustedParamTBase. Note that sizeof(T) serves as a check for a
complete type. Inside AdjustedParamTBase, we only pass complete
non-void types to:
std::is_trivially_copy_constructible<T>
std::is_trivially_move_constructible<T>
so we can safely drop the fallback case implemented with
std::false_type.
|
|
This PR refactor no-stable-modtime.m to use split-file
Signed-off-by: yicuixi <qin_17914@126.com>
|
|
Summary:
This was originally added in as a hack to work around CUDA's limitation
on allocation. The `libc` implementation now isn't even used for CUDA so
this code is never hit. Even if this case, this code never truly worked.
A true solution would be to use CUDA's virtual memory API instead to
allocate 2MiB slabs independenctly from the normal memory management
done in the stream.
|
|
Summary:
This somehow snuck back in.
|
|
There are a couple of places during function cloning where we may create
new callsite clone nodes. One of those places was correctly propagating
the assignment to which function clone it should call, and one was not.
Refactor this handling into a helper and use in both places so the newly
created callsite clones actually call the assigned callee function
clones.
|
|
I forgot to remove a bunch of the intermediary path.
That's what I get for not waiting my local build to finish.
Fixes: 47c1b650626043f0a8f8e32851617201751f9439
|
|
|
|
|
|
|
|
comparisons with `ConstantFPRange` (#159315)
Follow up of #158097
Similar to `simplifyAndOrOfICmpsWithConstants`, we can do so for
floating point comparisons.
|
|
Only enable Fortran tests when either the test compiler is set
explicitly, or in a runtimes bootstrapping build. A system-installed
Flang either may not exist, or too old to compiler our tests.
Fixes buildbot failure after landing #150722
https://lab.llvm.org/buildbot/#/builders/10/builds/13905
|
|
In addition to existing C/C++ tests, add Fortran-based tests. Fortran
tests will only run if a Fortran compiler is found. The first test is
for the unroll construct added in #144785.
|
|
During development I introduced the `%llvm_obj_root` substitution but later removed it as a better
solution became apparent. Revert this to the original substitution while keeping the new path.
Fixes: 4e1c996674cc340f290b0a528e2038e76494d8d4
|
|
This change adds support for type promotion for VectorType
Issue https://github.com/llvm/llvm-project/issues/136487
|
|
This patch adds atomic exchange operation which covers the following
C/C++ intrinsic functions:
- `__c11_atomic_exchange`
- `__atomic_exchange`
- `__atomic_exchange_n`
|
|
Fix the Missing enum element `Decl::OMPGroupPrivate` warning
|
|
Close https://github.com/llvm/llvm-project/issues/159780
|
|
Alive2: https://alive2.llvm.org/ce/z/8rX5Rk
Closes https://github.com/llvm/llvm-project/issues/118106.
|
|
This reverts commit 25e218d7562f1f360a8f112de2b771585cd922c3.
This is causing errors on the llvm-clang-aarch64-darwin builder related
to too many files being open.
|
|
This reverts commit 8d6470f717cb5c2d200f71dff09ee76a12f908a7.
This was causing a failure on the llvm-clang-aarch64-darwin builder when
using the external shell.
|
|
|
|
|
|
Now that all of the clang tests have been verified (and adjusted when
necessary) to work with lit's internal shell, we can enable it by
default, which this patch does.
This should make check-clang 10-15% faster in addition to providing
richer feedback on test failures.
Reviewers: AaronBallman, petrhosek, rnk, ilovepi, shafik, cmtice
Reviewed By: petrhosek, ilovepi, rnk, cmtice
Pull Request: https://github.com/llvm/llvm-project/pull/158465
|
|
Before this change, rm would assume that a symlink to a directory was
actually a directory and require the recursive flag to be passed,
differing from other shells. Given the change in lit is about the same
length as the test change would be (minus tests), I think it makes sense
to just support this in the internal shell.
Reviewers: cmtice, petrhosek, ilovepi
Reviewed By: petrhosek, cmtice, ilovepi
Pull Request: https://github.com/llvm/llvm-project/pull/158464
|
|
This test was using $'<content with escapes' to have bash interpret
shell escapes and then passing them to grep. The lexer/parser for lit's
internal shell does not support such sequences. Given this is the only
test in-tree that uses this functionality, it makes much more sense to
use a POSIX compliant utility like od to transform the file into hex and
then grep over that rather than modify the internal shell. This test
should remain portable as od should be widely available and we are only
using options specified in POSIX.
Reviewers: cmtice, petrhosek, ilovepi
Reviewed By: petrhosek, ilovepi
Pull Request: https://github.com/llvm/llvm-project/pull/158463
|
|
cat with no files passed to it is supposed to read from STDIN according
to POSIX. The builtin cat lacking this behavior led to the clang test in
dev-fd-fs.c to fail because it expected this behavior. This is a simple
modification and I do not think it is possible to rewrite the test
without this easily while preserving the semantics around named pipes.
Reviewers: petrhosek, arichardson, ilovepi, cmtice, jh7370
Reviewed By: jh7370, arichardson, ilovepi, cmtice
Pull Request: https://github.com/llvm/llvm-project/pull/158447
|
|
src/__support/math folder. (#154868)
Part of #147386
in preparation for: https://discourse.llvm.org/t/rfc-make-clang-builtin-math-functions-constexpr-with-llvm-libc-to-support-c-23-constexpr-math-functions/86450
|
|
The Mach-O file format has several load commands which specify the
location of data in the file in UInt32 offsets. lldb uses these same
structures to track the offsets of the binary in virtual address space
when it is running. Normally a binary is loaded in memory contiguously,
so this is fine, but on Darwin systems there is a "system shared cache"
where all system libraries are combined into one region of memory and
pre-linked. The shared cache has the TEXT segments for every binary
loaded contiguously, then the DATA segments, and finally a shared common
LINKEDIT segment for all binaries. The virtual address offset from the
TEXT segment for a libray to the LINKEDIT may exceed 4GB of virtual
address space depending on the structure of the shared cache, so this
use of a UInt32 offset will not work.
There was an initial instance of this issue that I fixed last November
in https://github.com/llvm/llvm-project/pull/117832 where I fixed this
issue for the LC_SYMTAB / `symtab_command` structure. But we have the
same issue now with three additional structures;
`linkedit_data_command`, `dyld_info_command`, and `dysymtab_command`.
For all of these we can see the pattern of `dyld_info.export_off +=
linkedit_slide` applied to the offset fields in ObjectFileMachO.
This defines local structures that mirror the Mach-O structures, except
that it uses UInt64 offset fields so we can reuse the same field for a
large virtual address offset at runtime. I defined ctor's from the
genuine structures, as well as operator= methods so the structures can
be read from the Mach-O binary into the standard object, then copied
into our local expanded versions of them. These structures are ABI in
Mach-O and cannot change their layout.
The alternative is to create local variables alongside these Mach-O load
command objects for the offsets that we care about, adjust those by the
correct VA offsets, and only use those local variables instead of the
fields in the objects. I took the approach of the local enhanced
structure in November and I think it is the cleaner approach.
rdar://160384968
|
|
attributes to use MayNeedCopy (#159477)
Ties the semantic checks for overwriting a asynchronous or volatile
value with a copy-out operation to the function
`evaluate::MayNeedCopy(..., /*forCopyOut=*/false)`. This should make the
checks more accurate and consistent with the lowering. The PR also adds
a default check that looks for the undesired behavior directly, in case
extension later modify what is possible.
A couple portability warnings are added where other compilers are over
restrictive.
Closes https://github.com/llvm/llvm-project/issues/137369
```
$ build/bin/flang -c ~/work/llvm-test-suite/Fortran/gfortran/regression/volatile8.f90 -pedantic
/home/akuhlenschmi/work/llvm-test-suite/Fortran/gfortran/regression/volatile8.f90:21:16: warning: The array section 'a(1_8:5_8:2_8)' should not be associated with dummy argument 'dummy8=' with VOLATILE attribute, unless the dummy is assumed-shape or assumed-rank [-Wvolatile-or-asynchronous-temporary]
call sub8 (a(1:5:2)) ! { dg-error "Array-section actual argument" }
^^^^^^^^
/home/akuhlenschmi/work/llvm-test-suite/Fortran/gfortran/regression/volatile8.f90:37:16: portability: The actual argument 's9dummy' should not be associated with dummy argument 'dummy9=' with VOLATILE attribute, because a temporary copy is required during the call [-Wportability]
call sub9 (s9dummy) ! { dg-error "Assumed-shape actual argument" }
^^^^^^^
/home/akuhlenschmi/work/llvm-test-suite/Fortran/gfortran/regression/volatile8.f90:55:17: portability: The actual argument 'a' should not be associated with dummy argument 'dummy10=' with VOLATILE attribute, because a temporary copy is required during the call [-Wportability]
call sub10 (a) ! { dg-error "Pointer-array actual argument" }
^
```
|
|
Fixes regression after e5bbaa9c8fb6e06dbcbd39404039cc5d31df4410.
e5500 accidentally still had the 64bit feature applied instead of
64bit-support.
|
|
Use the `Base` type alias from
https://github.com/llvm/llvm-project/pull/158433.
|
|
### Current state
We have FilterChooser class, which can be thought of as a **tree of
encodings**. Tree nodes are instances of FilterChooser itself, and come
in two types:
* A node containing single encoding that has *constant* bits in the
specified bit range, a.k.a. singleton node.
* A node containing only child nodes, where each child represents a set
of encodings that have the same *constant* bits in the specified bit
range.
Either of these nodes can have an additional child, which represents a
set of encodings that have some *unknown* bits in the same bit range.
As can be seen, the **data structure is very high level**.
The encoding tree represented by FilterChooser is then converted into a
finite-state machine (FSM), represented as **byte array**. The
translation is straightforward: for each node of the tree we emit a
sequence of opcodes that check encoding bits and predicates for each
encoding. For a singleton node we also emit a terminal "decode" opcode.
The translation is done in one go, and this has negative consequences:
* We miss optimization opportunities.
* We have to use "fixups" when encoding transitions in the FSM since we
don't know the size of the data we want to jump over in advance. We have
to emit the data first and then fix up the location of the jump. This
means the fixup size has to be large enough to encode the longest jump,
so **most of the transitions are encoded inefficiently**.
* Finally, when converting the FSM into human readable form, we have to
**decode the byte array we've just emitted**. This is also done in one
go, so we **can't do any pretty printing**.
### This PR
We introduce an intermediary data structure, decoder tree, that can be
thought as **AST of the decoder program**.
This data structure is **low level** and as such allows for optimization
and analysis.
It resolves all the issues listed above. We now can:
* Emit more optimal opcode sequences.
* Compute the size of the data to be emitted in advance, avoiding
fixups.
* Do pretty printing.
Serialization is done by a new class, DecoderTableEmitter, which
converts the AST into a FSM in **textual form**, streamed right into the
output file.
### Results
* The new approach immediately resulted in 12% total table size savings
across all in-tree targets, without implementing any optimizations on
the AST. Many tables observe ~20% size reduction.
* The generated file is much more readable.
* The implementation is arguably simpler and more straightforward (the
diff is only +150~200 lines, which feels rather small for the benefits
the change gives).
|
|
#159505 (#159859)
We can't give a correct answer for dependent types, so for now just
report no ptrauth involves if the type being queried is dependent. In
future we may want to distinguigh the `None` vs `Dependent` cases but
that does not seem warranted for now.
Fixes #159505
|
|
(#159839)
LiveRangeEdit's rematerialization checking logic is used in two quite
different ways. For SplitKit and InlineSpiller, we're analyzing all defs
associated with a live interval, doing that analysis up front, and then
using the result a bit later. The RegisterCoalescer, we're analysing
exactly one ValNo at a time, and using the legality result immediately.
LRE had a checkRematerializable which existed basically to adapt the
later into the former usage model.
Instead, this change bypasses the ScannedRemat and Remattable
structures, and directly queries the underlying routines. This is easy
to read, and makes it more clear as to which uses actually need the
deferred analysis. (A following change may try to unwind that too, but
it's not strictly NFC.)
|
|
Summary:
This patch has broken the `libc` build bot. I could work around that but
the changes seem unnecessary.
This reverts commit 9ba844eb3a21d461c3adc7add7691a076c6992fc.
|
