Dmitry Makogon [Fri, 10 Feb 2023 09:00:16 +0000 (16:00 +0700)]
[LVI] Don't traverse uses when calculating range at use
This effectively reverts 5c38c6a and 4f772b0.
A recently introduced LazyValueInfo::getConstantRangeAtUse returns incorrect
ranges for values in certain cases. One such example is described in PR60629.
The issue has something to do with traversing PHI uses of a value transitively.
As nikic pointed out, we're effectively reasoning about values from different
loop iterations.
In the faulting test case, CVP made a miscompilation because the calculated
range for a shift argument was incorrect. It returned empty-set, however it is
clearly not a dead code. CVP then erased the shift instruction because
of empty range.
Dmitry Makogon [Fri, 10 Feb 2023 09:30:47 +0000 (16:30 +0700)]
[LVI][CVP] Add test for miscompilation by CVP due to incorrect range returned by LVI
This adds a test case from PR60629 which shows a miscompilation by CVP.
Archibald Elliott [Fri, 10 Feb 2023 09:59:46 +0000 (09:59 +0000)]
[NFC][TargetParser] Replace uses of llvm/Support/Host.h
The forwarding header is left in place because of its use in
`polly/lib/External/isl/interface/extract_interface.cc`, but I have
added a GCC warning about the fact it is deprecated, because it is used
in `isl` from where it is included by Polly.
OCHyams [Fri, 10 Feb 2023 09:27:37 +0000 (09:27 +0000)]
[Assignment Tracking][mem2reg] Remove overly defensive assert
The assert fires if a store to an alloca with no linked dbg.assigns has linked
dbg.assigns. This can happen in the wild due to optimisations dropping the
alloca's debug info so we shouldn't assert against it.
Reviewed By: jryans
Differential Revision: https://reviews.llvm.org/D143153
OCHyams [Fri, 10 Feb 2023 09:26:26 +0000 (09:26 +0000)]
[Assignment Tracking][SROA] Delete dbg.assigns linked to rewritten stores
AggLoadStoreRewriter splits aggregate loads and stores into scalars (before the
alloca is split up). The new stores and debug intrinsics are already wired up
correctly - we just need to also delete the dbg.assign that is linked to the
split to-be-deleted store too.
Reviewed By: jmorse
Differential Revision: https://reviews.llvm.org/D142882
Chuanqi Xu [Fri, 10 Feb 2023 09:46:18 +0000 (17:46 +0800)]
Revert "[C++20] [Modules] [ClangScanDeps] Enable to print make-style dependency file within P1689 format (4/4)"
This reverts commit
e1354763b6e641e45cc2371270883fcd26edf705.
There is a build failure in m68k-linux testing bot
(https://lab.llvm.org/buildbot/#/builders/192/builds/267), which is
weird. Revert this for now and look at the reasons.
Samuel Parker [Wed, 8 Feb 2023 14:09:06 +0000 (14:09 +0000)]
[WebAssembly] Additional patterns for pmin/pax
Each operation was missing their inverted condition using olt or ogt.
Also, as we don't need to discern +/-0, I think we should also be
able to use ole and oge.
Differential Revision: https://reviews.llvm.org/D143581
Valentin Clement [Fri, 10 Feb 2023 09:25:01 +0000 (10:25 +0100)]
[flang][NFC] Clean up polymorphic-temp.f90
Marco Elver [Fri, 10 Feb 2023 08:34:08 +0000 (09:34 +0100)]
[SanitizerBinaryMetadata] Support ignore list
For large projects it will be required to opt out entire subdirectories.
In the absence of fine-grained control over the flags passed via the
build system, introduce -fexperimental-sanitize-metadata-ignorelist=.
The format is identical to other sanitizer ignore lists, and its effect
will be to simply not instrument either functions or entire modules
based on the rules in the ignore list file.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D143664
OCHyams [Fri, 10 Feb 2023 09:20:53 +0000 (09:20 +0000)]
[NFC][Assignment Tracking] Remove lifetime intrinsics from some tests
The intrinsics don't add anything to the tests and the tests are easier to
debug without the additional noise.
Some SSA value names have changed as a result of no longer visiting the
intrinsics.
Reviewed By: jryans
Differential Revision: https://reviews.llvm.org/D143141
Max Kazantsev [Fri, 10 Feb 2023 09:05:16 +0000 (16:05 +0700)]
[Test][SCEV] Add tests where multiple assumes can be used to improve trip multiple
Add tests combining assume on trip count divisibility (TV % VF) and minimum/maximum
values (TC > N, TC < M).
Patch by Alon Kom!
Differential Revision: https://reviews.llvm.org/D143337
Benjamin Kramer [Fri, 10 Feb 2023 09:22:18 +0000 (10:22 +0100)]
[bazel] Add missing dependency after
687f78210d0
Tobias Hieta [Fri, 10 Feb 2023 07:33:32 +0000 (08:33 +0100)]
[NFC] convert compiler-rt/lib/dfsan/scripts/build-libc-list.py to python3 syntax
I found a few Python files not using Python 3 syntax in the tree
when trying to apply reformatting to them. This was converted with
2to3 and the changes seemed sane.
Reviewed By: MaskRay, browneee
Differential Revision: https://reviews.llvm.org/D143701
Siva Chandra Reddy [Fri, 10 Feb 2023 09:03:05 +0000 (09:03 +0000)]
[libc][Obvious] Include MPFRWrapper and testutils only if tests are enabled.
Mikhail Goncharov [Fri, 10 Feb 2023 09:03:37 +0000 (10:03 +0100)]
[bazel] fix build for
6470706bc0ed
chenglin.bi [Fri, 10 Feb 2023 08:49:56 +0000 (16:49 +0800)]
[Reland][LSR] Hoist IVInc to loop header if its all uses are in the loop header
Original code will cause crash when the load/store memory type is structure because isIndexedLoadLegal/isIndexedStore doesn't support struct type.
So we limit the load/store memory type to integer.
Origin commit message:
When the latch block is different from header block, IVInc will be expanded in the latch loop. We can't generate the post index load/store this case.
But if the IVInc only used in the loop, actually we still can use the post index load/store because when exit loop we don't care the last IVInc value.
So, trying to hoist IVInc to help backend to generate more post index load/store.
Fix #53625
Reviewed By: eopXD
Differential Revision: https://reviews.llvm.org/D138636
Siva Chandra Reddy [Thu, 9 Feb 2023 05:42:12 +0000 (05:42 +0000)]
[libc] Run libc tests unconditionally, even if there are no source changes.
Before this change, the test binaries were executed only if the deps
changed. This change makes the test binaries run unconditionally. This
is more in line with the rest of LLVM. Future patches will print test
statistics etc., much like the rest of LLVM.
Reviewed By: gchatelet
Differential Revision: https://reviews.llvm.org/D143627
Matthias Springer [Fri, 10 Feb 2023 08:30:21 +0000 (09:30 +0100)]
[mlir][bufferization] Support multiple leaves in EmptyTensorElimination
Support cases where a source tensor can be traced back to multiple possible tensor.empty ops.
Differential Revision: https://reviews.llvm.org/D142130
Sandeep Kosuri [Fri, 10 Feb 2023 08:32:50 +0000 (02:32 -0600)]
[OPENMP][NFC] added loop bind to the support page
Max Kazantsev [Fri, 10 Feb 2023 08:20:03 +0000 (15:20 +0700)]
[SimplifyIndVar][NFC] Refactor Binary Operator's flag strengthening
Extract complex logic of Binary Operator's flag strengthening to a separate
method in order to reuse it.
Patch by Aleksandr Popov!
Differential Revision: https://reviews.llvm.org/D143562
Reviewed By: mkazantsev
Chuanqi Xu [Fri, 10 Feb 2023 08:13:46 +0000 (16:13 +0800)]
[NFC] Add test to show that preprocess an import decl won't require to load it actually
Close https://github.com/llvm/llvm-project/issues/59287
This is addressed in D137526 but I forgot to add a test for it.
Uday Bondhugula [Fri, 10 Feb 2023 08:05:04 +0000 (13:35 +0530)]
[MLIR] Fold away divs and mods in affine ops with operand info
Fold away divs and mods in affine maps exploiting operand info during
canonicalization. This simplifies affine map applications such as the ones
below:
```
// Simple ones.
affine.for %i = 0 to 32 {
affine.load %A[%i floordiv 32]
affine.load %A[%i mod 32]
affine.load %A[2 * %i floordiv 64]
affine.load %A[(%i mod 16) floordiv 16]
...
}
// Others.
affine.for %i = -8 to 32 {
// Will be simplified %A[0].
affine.store %cst, %A[2 + (%i - 96) floordiv 64] : memref<64xf32>
}
```
Reviewed By: springerm
Differential Revision: https://reviews.llvm.org/D143456
Chuanqi Xu [Fri, 10 Feb 2023 08:02:31 +0000 (16:02 +0800)]
[NFC] Remove the unused parameter introduced in e135476
I introduced an unused parameter due to an oversight during rebasing.
Now the patch removes the parameter.
Jean Perier [Fri, 10 Feb 2023 07:56:53 +0000 (08:56 +0100)]
[flang][hlfir] Ramp-up support of implicit interface mismatches
There is a lot of Fortran code that takes advantage of F77 implicit
interface to pass arguments with a different type than those from
the subprogram definition (which is well defined if the storage
and passing convention are the same or compatible).
When the definition and calls are in different files, there is nothing
special to do: the actual arguments are already used to compute the
call interface.
The trouble for lowering comes when the definition is in the same
compilation unit (Semantics raises warning). Then, lowering will
be provided with the interface from the definition to prepare the
argument, and this leads to many ad-hoc handling (see
builder.convertWithSemantics) in the current lowering to cope
with the dummy/actual mismatches on a case by case basis. The
current lowering to FIR is not even complete for all mismatch cases that
can be found in the wild (see https://github.com/llvm/llvm-project/issues/60550),
it is crashing or hitting asserts for many of the added tests.
For HLFIR, instead of coping on a case by case basis, the call
interface will be recomputed according to the actual arguments when
calling an external procedure that can be called with an explicit
interface.
One extra case still has to be handled manually because it may happen
in calls with explicit interfaces: passing a character procedure
designator to a non character procedure dummy (and vice-versa) is widely
accepted even with explicit interfaces (and flang semantic accepts it).
Yet, this "mismatch" cannot be dealt with a simple fir.convert because
character dummy procedure are passed with a different passing
convention: an extra argument is hoisted for the result length (in FIR,
there is no extra argument yet, but the MLIR func argument is a
tuple<fir.boxproc, len>).
Differential Revision: https://reviews.llvm.org/D143636
Christian Ulmann [Fri, 10 Feb 2023 07:21:46 +0000 (08:21 +0100)]
[mlir][llvm] Fix TBAA verfication crash
This commit fixes a crash of the TBAA verification that happened due to
accessing memory through invalid pointers. A DenseMap does not guarantee
that pointers to its elements remain valid after additional elements
are inserted.
A testcase that caused this crash had more than 100 TBAA metadata
operations and thus no test is added. Instead, there is now an assertion
that ensures that the graph class is used correctly.
Reviewed By: vzakhari
Differential Revision: https://reviews.llvm.org/D143653
Pierre van Houtryve [Wed, 25 Jan 2023 13:06:09 +0000 (14:06 +0100)]
[RFC][GISel] Add a way to ignore COPY instructions in InstructionSelector
RFC to add a way to ignore COPY instructions when pattern-matching MIR in GISel.
- Add a new "GISelFlags" class to TableGen. Both `Pattern` and `PatFrags` defs can use it to alter matching behaviour.
- Flags start at zero and are scoped: the setter returns a `SaveAndRestore` object so that when the current scope ends, the flags are restored to their previous values. This allows child patterns to modify the flags without affecting the parent pattern.
- Child patterns always reuse the parent's pattern, but they can override its values. For more examples, see `GlobalISelEmitterFlags.td` tests.
- [AMDGPU] Use the IgnoreCopies flag in BFI patterns, which are known to be bothered by cross-regbank copies.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D136234
Pierre van Houtryve [Tue, 24 Jan 2023 09:33:29 +0000 (10:33 +0100)]
[AMDGPU] Run unmerge combines post regbankselect
RegBankSelect can insert G_UNMERGE_VALUES in a lot of places which
left us with a lot of unmerge/merge pairs that could be simplified.
These often got in the way of pattern matching and made codegen
worse.
This patch:
- Makes the necessary changes to the merge/unmerge combines so they can run post RegBankSelect
- Adds relevant unmerge combines to the list of RegBankSelect combines for AMDGPU
- Updates some tablegen patterns that were missing explicit cross-regbank copies (V_BFI patterns were causing constant bus violations with this change).
This seems to be mostly beneficial for code quality.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D142192
Max Kazantsev [Fri, 10 Feb 2023 06:56:33 +0000 (13:56 +0700)]
[Test] Add tests where we can replace IV check with invariant check basing on predicated backedge cond
wanglei [Fri, 10 Feb 2023 06:35:18 +0000 (14:35 +0800)]
[LoongArch] Convert test to opaque pointer. NFC
lizhijin [Fri, 10 Feb 2023 06:42:33 +0000 (14:42 +0800)]
[SVE] Add intrinsics for logical/bitwise operations that explicitly undefine the result for inactive lanes
This patch adds new intrinsics for logical/bitwise operations and
changes the lowering for the following builtins to emit calls to
the new aarch64.sve.###.u intrinsics.
svand_x
svand_n_x
svorr_x
svorr_n_x
sveor_x
sveor_n_x
svbic_x
svbic_n_x
Reviewed By: paulwalker-arm
Differential Revision: https://reviews.llvm.org/D143499
gonglingqin [Fri, 10 Feb 2023 05:57:55 +0000 (13:57 +0800)]
[LoongArch] Implement the convertSelectOfConstantsToMath hook
Normally, the ISD::SELECT is lowered to maskeqz + masknez. This is
inefficient when operands are constants that can be computed easily.
To avoid that, override TargetLowering::convertSelectOfConstantsToMath.
Differential Revision: https://reviews.llvm.org/D143621
Amara Emerson [Fri, 10 Feb 2023 05:56:02 +0000 (21:56 -0800)]
Inliner: Address missed review comments for D143624
Max Kazantsev [Fri, 10 Feb 2023 04:56:08 +0000 (11:56 +0700)]
[SimpleLoopUnswitch] Inject loop-invariant conditions and unswitch them when it's profitable
Based on https://discourse.llvm.org/t/rfc-inject-invariant-conditions-to-loops-to-enable-unswitching-and-constraint-elimination
This transform attempts to handle the following loop:
```
for (...) {
x = <some variant>
if (x <u C1) {} else break;
if (x <u C2) {} else break;
}
```
Here `x` is some loop-variant value, and `C1` and `C2` are loop invariants.
As we see, this loop has no invariant checks we can unswitch on. However, there is an
invariant condition that can make the second check redundant. Specifically, it is `C1 <=u C2`.
We can modify this code in the following way:
```
for (...) {
x = <some variant>
if (x <u C1) {} else break;
if (C1 <=u C2) {
/* no check is required */
}
else {
// do the check normally
if (x <u C2) {} else break;
}
}
```
Now we have an invariant condition `C1 <=u C2` and can unswitch on it.
This patch introduces the basic version of this transform, with some limitations,
all of them seem liftable (but needs more work & testing):
- All checks are `ult` condition;
- All branches in question stay in loop if the said condition is true and leave it otherwise;
- All in-loop branches are hot enough;
There is also a room for improvement cost model. So far we evalutate the cost of
unswitching this newly injected invariant branch the same as if we would unswitch
on 2nd condition, which is not exactly precise (but also not grossly wrong).
Differential Revision: https://reviews.llvm.org/D136233
Reviewed By: skatkov
Jonas Devlieghere [Fri, 10 Feb 2023 01:24:10 +0000 (17:24 -0800)]
[lldb] Hoist code to create StructuredData into DiagnosticEventData (NFC)
Hoist the code that creates a StructuredData dictionary from a
diagnostic event into the DiagnosticEventData. This addresses Ismail's
code review feedback from D143687.
Differential revision: https://reviews.llvm.org/D143694
Mircea Trofin [Fri, 10 Feb 2023 05:13:41 +0000 (21:13 -0800)]
[mlgo] Fix test after D143624
Kai Luo [Fri, 10 Feb 2023 04:52:31 +0000 (04:52 +0000)]
[CMake] Fix -DBUILD_SHARED_LIBS=on builds after D137534
Yingchi Long [Tue, 24 Jan 2023 13:25:50 +0000 (21:25 +0800)]
[InstCombine] combine intersection for inequality icmps
```
define i1 @src(i32 %A) {
%mask1 = and i32 %A, 15 ; 0x0f
%tst1 = icmp eq i32 %mask1, 3 ; 0x03
%mask2 = and i32 %A, 255 ; 0xff
%tst2 = icmp eq i32 %mask2, 243; 0xf3
%res = or i1 %tst1, %tst2
ret i1 %res
}
```
->
```
define i1 @tgt(i32 %A) {
%1 = and i32 %A, 15
%res = icmp eq i32 %1, 3
ret i1 %res
}
```
Proof: https://alive2.llvm.org/ce/z/4AyvcE
Assume that `(B & D) & (C ^ E) == 0`, and `(B & D) == D || (B & D) == B`,
transforms:
```
(icmp ne (A & B), C) & (icmp ne (A & D), E)
-> (icmp ne (A & (B&D)), (C&E))
```
Fixes: https://github.com/llvm/llvm-project/issues/59680
Reviewed By: spatel, bcl5980
Differential Revision: https://reviews.llvm.org/D140666
Yingchi Long [Thu, 19 Jan 2023 09:14:15 +0000 (17:14 +0800)]
[InstCombine] precommit tests for D140666
Differential Revision: https://reviews.llvm.org/D142090
Dave Lee [Sat, 4 Feb 2023 05:44:07 +0000 (21:44 -0800)]
[lldb] Remove unused CommandObjectRegexCommand::m_max_matches (NFC)
Michael Buch [Fri, 10 Feb 2023 03:28:28 +0000 (03:28 +0000)]
Revert "[lldb][DWARFASTParserClang] Correctly resolve imported namespaces during expression evaluation"
This reverts commit
1ba6ec0ba906472661506ef7bd2f0bf4efe4657e.
Fails on linux buildbots.
Differential Revision: https://reviews.llvm.org/D143398
Michael Buch [Fri, 10 Feb 2023 03:24:52 +0000 (03:24 +0000)]
Revert "[llvm][dsymutil] Add DW_TAG_imported_declaration to accelerator table"
This reverts commit
ccee9b7839a182fc692a65f563abf76f81dd436c.
This started failing on Linux buildbots. The executable wasn't generated
correctly.
Differential Revision: https://reviews.llvm.org/D143458
Chuanqi Xu [Fri, 10 Feb 2023 03:22:33 +0000 (11:22 +0800)]
[C++20] [Modules] [ClangScanDeps] Enable to print make-style dependency file within P1689 format (4/4)
Required in https://reviews.llvm.org/D137534.
The build systems needs the information to know that "header X changed,
scanning may have changed, so please rerun scanning". Although it is
possible to get the information by running clang-scan-deps for the
second time with make format, it is not user friendly clearly.
Reviewed By: jansvoboda11
Differential Revision: https://reviews.llvm.org/D139168
Kai Luo [Fri, 10 Feb 2023 03:17:39 +0000 (03:17 +0000)]
[DwarfGenerator] Emit dwarf address section when dwarf version is not less than 4
Some targets (like AIX) might not feature dwarf address section due to low dwarf version. Check before emitting one.
Fixed DebugInfo unit test failures in https://lab.llvm.org/buildbot/#/builders/214/builds/5739.
Reviewed By: qiucf
Differential Revision: https://reviews.llvm.org/D143561
Mehdi Amini [Fri, 10 Feb 2023 03:13:48 +0000 (19:13 -0800)]
Remove empty MLIRMemRefUtils library (NFC)
Shengchen Kan [Tue, 7 Feb 2023 08:04:05 +0000 (16:04 +0800)]
[X86][MC][NFC] Refine code in X86MCCodeEmitter.cpp about opcode prefix
1. Make code clearer by separating the logic of setting bits from the
logic of how a prefix is encoded
2. Extract common code into functions to avoid code duplication
3. Return a enum rather a boolean to ehance scalability and uniform
the behavior of functions
Reviewed By: pengfei, craig.topper
Differential Revision: https://reviews.llvm.org/D143471
rkayaith [Tue, 25 Oct 2022 19:17:14 +0000 (15:17 -0400)]
[YAML] Trim trailing whitespace from plain scalars
In some cases plain scalars are currently parsed with a trailing
newline. In particular this shows up often when parsing JSON files, e.g.
note the `\n` after `456` below:
```
$ cat test.yaml
{
"foo": 123,
"bar": 456
}
$ yaml-bench test.yaml -canonical
%YAML 1.2
---
!!map {
? !!str "foo"
: !!str "123",
? !!str "bar"
: !!str "456\n",
}
...
```
The trailing whitespace ends up causing the conversion of the scalar to
int/bool/etc. to fail, causing the issue seen here:
https://github.com/llvm/llvm-project/issues/15877
From reading the YAML spec (https://yaml.org/spec/1.2.2/#733-plain-style)
it seems like plain scalars should never end with whitespace, so this
change trims all trailing whitespace characters from the
value (specifically `b-line-feed`, `b-carriage-return`, `s-space`, and
`s-tab`).
Reviewed By: scott.linder
Differential Revision: https://reviews.llvm.org/D137118
Jie Fu [Fri, 10 Feb 2023 02:47:18 +0000 (10:47 +0800)]
[Modules][Test][NFC] Fix -Wsign-compare in clang/unittests/Lex/ModuleDeclStateTest.cpp
In file included from /data/jiefu/llvm-project/clang/unittests/Lex/ModuleDeclStateTest.cpp:22:
/data/jiefu/llvm-project/third-party/unittest/googletest/include/gtest/gtest.h:1526:11: error: comparison of integers of different signs: 'const unsigned long' and 'const int' [-Werror,-Wsign-compare]
if (lhs == rhs) {
~~~ ^ ~~~
/data/jiefu/llvm-project/third-party/unittest/googletest/include/gtest/gtest.h:1553:12: note: in instantiation of function template specialization 'testing::internal::CmpHelperEQ<unsigned long, int>' requested here
return CmpHelperEQ(lhs_expression, rhs_expression, lhs, rhs);
^
/data/jiefu/llvm-project/clang/unittests/Lex/ModuleDeclStateTest.cpp:124:3: note: in instantiation of function template specialization 'testing::internal::EqHelper::Compare<unsigned long, int, nullptr>' requested here
EXPECT_EQ(Callback->importNamedModuleNum(), 0);
^
/data/jiefu/llvm-project/third-party/unittest/googletest/include/gtest/gtest.h:2027:54: note: expanded from macro 'EXPECT_EQ'
EXPECT_PRED_FORMAT2(::testing::internal::EqHelper::Compare, val1, val2)
^
1 error generated.
Chuanqi Xu [Fri, 10 Feb 2023 02:40:17 +0000 (10:40 +0800)]
[C++20] [Modules] [ClangScanDeps] Allow clang-scan-deps to without specified compilation database in P1689 (3/4)
In a private chat with @ben.boeckel , we get in consensus it would be
great for cmake if the invocation of clang-scan-deps can get rid of
compilation database. Due to the compilation database can't do very well
for the files which are not existed yet. @ben.boeckel may have more
context to add here.
This patch should be innocent for others usages.
Reviewed By: jansvoboda11
Differential Revision: https://reviews.llvm.org/D137534
chenglin.bi [Fri, 10 Feb 2023 02:31:44 +0000 (10:31 +0800)]
[InstCombine] Look through truncate to fold icmp with intrinsics
The output of intrinsic functions like ctpop, cttz, ctlz have limited range from 0 to bitwidth. So if the truncate destination type can hold the source bitwidth size, we can just ignore the truncate and use the truncate src to do combination.
Alive2 proofs:
https://alive2.llvm.org/ce/z/9D_-qP
Reviewed By: spatel
Differential Revision: https://reviews.llvm.org/D143368
Chuanqi Xu [Fri, 10 Feb 2023 02:26:35 +0000 (10:26 +0800)]
[C++20] [Modules] [ClangScanDeps] Add ClangScanDeps support for C++20 Named Modules in P1689 format (2/4)
Close https://github.com/llvm/llvm-project/issues/51792
Close https://github.com/llvm/llvm-project/issues/56770
This patch adds ClangScanDeps support for C++20 Named Modules in P1689
format. We can find the P1689 format at:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1689r5.html.
After we land the patch, we're able to compile C++20 Named
Modules with CMake! And although P1689 is written by kitware people,
other build systems should be able to use the format to compile C++20
Named Modules too.
TODO: Support header units in P1689 Format.
TODO2: Support C++20 Modules in the full dependency format of
ClangScanDeps. We also want to support C++20 Modules and clang modules
together according to
https://discourse.llvm.org/t/how-should-we-support-dependency-scanner-for-c-20-modules/66027.
But P1689 format cares about C++20 Modules only for now. So let's focus
on C++ Modules and P1689 format. And look at the full dependency format
later.
I'll add the ReleaseNotes and Documentations after the patch get landed.
Reviewed By: jansvoboda11
Differential Revision: https://reviews.llvm.org/D137527
Chuanqi Xu [Fri, 10 Feb 2023 02:11:33 +0000 (10:11 +0800)]
[C++20] [Modules] [NFC] Add Preprocessor methods for named modules - for ClangScanDeps (1/4)
This patch prepares the necessary interfaces in the preprocessor part
for D137527 since we need to recognize if we're in a module unit, the
module kinds and the module declaration and the module we're importing
in the preprocessor.
Differential Revision: https://reviews.llvm.org/D137526
Michael Buch [Thu, 9 Feb 2023 16:00:04 +0000 (16:00 +0000)]
[lldb][Test] Check compiler in data forammter compiler version checks
**Summary**
The compiler version check wouldn't make sense for non-GCC
compilers, so check for the compiler too.
Differential Revision: https://reviews.llvm.org/D143656
Michael Buch [Mon, 6 Feb 2023 13:54:32 +0000 (13:54 +0000)]
[lldb][DWARFASTParserClang] Correctly resolve imported namespaces during expression evaluation
**Summary**
This patch makes the expression evaluator understand
namespace aliases.
This will become important once `std::ranges` become
more widespread since `std::views` is defined as:
```
namespace std {
namespace ranges::views {}
namespace views = ranges::views;
}
```
**Testing**
* Added API test
Differential Revision: https://reviews.llvm.org/D143398
Michael Buch [Mon, 6 Feb 2023 14:42:41 +0000 (14:42 +0000)]
[llvm][dsymutil] Add DW_TAG_imported_declaration to accelerator table
**Summary**
After this patch, `dsymutil` will preserve `DW_TAG_imported_declarations`
entries in accelerator tables.
This allows consumers to resolve imported declarations even on
executables processsed through dsymutil.
This helps consumers, particularly LLDB's expression evaluator,
to resolve imported declarations (i.e., useful for namespace aliases
in C++) more efficiently.
**Testing**
* Added unit-test
Differential Revision: https://reviews.llvm.org/D143458
Michael Buch [Mon, 6 Feb 2023 13:53:08 +0000 (13:53 +0000)]
[llvm][DebugInfo] Add DW_TAG_imported_declaration to accelerator tables
**Summary**
After this patch, `DW_TAG_imported_declaration`s will be emitted into
the DWARF accelerator tables (under `.apple_namespaces`)
**Motivation**
Currently LLDB expression evaluation doesn't see through namespace
aliases. This is because LLDB only considers namespaces that are
part of `.apple_namespaces` when building a nested namespace
identifier for C++, which currently doesn't include import
declarations. The alternative to putting imports into accelerator
tables is to do a linear scan of a `DW_TAG_namespace` and look
for import declarations that look like they would satisfy the lookup
request, which is prohibitively expensive.
**Testing**
* Added unit-test
Differential Revision: https://reviews.llvm.org/D143397
Jan Korous [Fri, 10 Feb 2023 01:01:30 +0000 (17:01 -0800)]
[-Wunsafe-buffer-usage] Emit Fix-Its only for C++20 and later standards
The transformation strategy we are bringing up heavily relies on std::span which was introduced as part of C++20.
Differential Revision: https://reviews.llvm.org/D143455
Hanhan Wang [Fri, 10 Feb 2023 01:24:26 +0000 (17:24 -0800)]
[mlir][tensor] Add shape inference methods to tensor::PackOp.
Reviewed By: mravishankar
Differential Revision: https://reviews.llvm.org/D143686
Louis Dionne [Thu, 9 Feb 2023 23:20:20 +0000 (15:20 -0800)]
[libc++] Guard the fix to CityHash behind ABI v2
As explained in a comment in https://reviews.llvm.org/D134124, we tried
landing this unconditionally but this actually bit some users who were
sharing std::unordered_map across an ABI boundary. This shows that the
ABI break is not benign and it should be guarded behind ABI v2.
Differential Revision: https://reviews.llvm.org/D143688
Amara Emerson [Thu, 9 Feb 2023 03:52:00 +0000 (19:52 -0800)]
Inlining: Run the legacy AlwaysInliner before the regular inliner.
We have several situations where it's beneficial for code size to ensure that every
call to always-inline functions are inlined before normal inlining decisions are
made. While the normal inliner runs in a "MandatoryOnly" mode to try to do this,
it only does it on a per-SCC basis, rather than the whole module. Ensuring that
all mandatory inlinings are done before any heuristic based decisions are made
just makes sense.
Despite being referred to the "legacy" AlwaysInliner pass, it's already necessary
for -O0 because the CGSCC inliner is too expensive in compile time to run at -O0.
This also fixes an exponential compile time blow up in
https://github.com/llvm/llvm-project/issues/59126
Differential Revision: https://reviews.llvm.org/D143624
Uday Bondhugula [Thu, 9 Feb 2023 22:38:39 +0000 (04:08 +0530)]
[MLIR] Fix non-deterministic generation from buffer-deallocation pass
The buffer-deallocation pass generates a different output on each run
due to an unstable iteration order.
Fixes: https://github.com/llvm/llvm-project/issues/59118
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D143622
Craig Topper [Thu, 9 Feb 2023 23:19:18 +0000 (15:19 -0800)]
[ValueTracking] Replace an always false condition with an assert. NFC
The one caller of this function already checked that V isn't a
Constant.
Alternatively, we could remove the check from the caller if reviewers
prefer.
Reviewed By: spatel
Differential Revision: https://reviews.llvm.org/D143677
Krzysztof Drewniak [Thu, 9 Feb 2023 22:56:25 +0000 (22:56 +0000)]
Add missing cases to clang switch after D141863
Turns out there's a switch on APFloat semantics in clang I wasn't
aware of, fix the build error here.
Differential Revision: https://reviews.llvm.org/D143684
Haojian Wu [Wed, 8 Feb 2023 08:41:55 +0000 (09:41 +0100)]
[Tooling/Inclusion] Use the StdSpecialSymbolMap.inc in the stdlib
Remove a special-case in clangd.
Differential Revision: https://reviews.llvm.org/D143559
Jacek Caban [Thu, 9 Feb 2023 22:46:20 +0000 (00:46 +0200)]
[llvm-lib] Write object files in reversed order.
This isn't strictly needed, but this matches how MSVC lib.exe writes to
archives, so this makes llvm-lib more compatible and simplifies comparing
output between tools.
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D143536
Fangrui Song [Thu, 9 Feb 2023 22:38:17 +0000 (14:38 -0800)]
[ELF][docs] Mention LLD_REPRODUCE and LLD_VERSION
Reviewed By: peter.smith
Differential Revision: https://reviews.llvm.org/D143600
Slava Zakharin [Thu, 9 Feb 2023 22:10:36 +0000 (14:10 -0800)]
[flang] Fixed build after D142977. Added missing link to HLFIRDialect.
Differential Revision: https://reviews.llvm.org/D142977
Krzysztof Drewniak [Tue, 10 Jan 2023 21:18:10 +0000 (21:18 +0000)]
[llvm][APFloat] Add NaN-in-negative-zero formats by AMD and GraphCore
AMD, GraphCore, and Qualcom have published a standard for 8-bit floats that
differs from the 8-bit floats defined by Nvidia, Intel, and ARM. This
commit adds support for these alternate 8-bit floats to APFloat in
order to enable their usage in MLIR. These formats are presented in
the paper at https://arxiv.org/abs/2206.02915 and are implemented in
GRaphCore hardware whose ISA is available at
https://docs.graphcore.ai/projects/isa-mk2-with-fp8/en/latest/_static/TileVertexISA-IPU21-1.3.1.pdf .
In these formats, like the existing Float8E4M3FN, there are no
infinity values and there is only one NaN. Unlike in that format,
however, the NaN values is 0x80, which would be negative 0 in IEEE
formats. This means that these formats also make 0 unsigned.
To allow for these new variant semantics, this commit adds
fltNanEncoding, which can be IEEE (the default), AllOnes (used by
Fleat8E4M3FN), or NegativeZero (used by the new formats,
Float8E5M2FNUZ and Float8E4M3FNUZ). Normalization, arithmetic, and
other such routines have been updated to account for the potential
variant semantics.
The two new formats are Float8E5M2FNUZ (5 bits exponent, 2 bits
mantissa, finite, unsigned zero) and Float8E4M3FNUZ (4 bits exponent,
3 bits mantissa, finite, unsigned zero).
Reviewed By: jakeh-gc, reedwm, lattner
Differential Revision: https://reviews.llvm.org/D141863
Michael Jones [Fri, 3 Feb 2023 21:13:23 +0000 (13:13 -0800)]
[libc][NFC] reorganize structs in printf
Previously the type description structs were defined in the parser. For
the fuzzing targets we'll need to use those, so I've moved them into
core_structs.h. Additionally I've renamed the function for determining
the TypeDesc from a given type. Previously it shared its name with
get_type_desc which is a related but separate function that is a part of
the parser.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D143595
Krzysztof Drewniak [Mon, 9 Jan 2023 16:04:09 +0000 (16:04 +0000)]
[mlir][Memref] Add memref.memory_space_cast and its lowerings
Address space casts are present in common MLIR targets (LLVM, SPIRV).
Some planned rewrites (such as one of the potential fixes to the fact
that the AMDGPU backend requires alloca() to live in address space 5 /
the GPU private memory space) may require such casts to be inserted
into MLIR code, where those address spaces could be represented by
arbitrary memory space attributes.
Therefore, we define memref.memory_space_cast and its lowerings.
Depends on D141293
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D141148
Guillaume Chatelet [Thu, 9 Feb 2023 21:35:16 +0000 (21:35 +0000)]
[libc] Fix layering for bazel
Owen Pan [Wed, 8 Feb 2023 02:36:28 +0000 (18:36 -0800)]
[clang-format] Insert a space between a numeric UDL and a dot
Fixes #60576.
Differential Revision: https://reviews.llvm.org/D143546
Jonas Devlieghere [Thu, 9 Feb 2023 21:17:12 +0000 (13:17 -0800)]
[DWARFLinker] Fix typo and improve comments (NFC)
Fix a typo and improve comments to match the LLVM coding style.
Jonas Devlieghere [Thu, 9 Feb 2023 21:00:45 +0000 (13:00 -0800)]
[lldb] Add the ability to remove diagnostic callbacks
Add the ability to remove diagnostic callbacks. This is necessary for
diagnostics who's lifetime is tied to objects that can be destroyed.
Differential revision: https://reviews.llvm.org/D143548
Jay Foad [Fri, 3 Feb 2023 11:29:45 +0000 (11:29 +0000)]
[AMDGPU] Refactor multiclass FLAT_Atomic_Pseudo. NFC.
This is just for consistency with FLAT_Global_Atomic_Pseudo.
Differential Revision: https://reviews.llvm.org/D143662
Nicolas Vasilache [Thu, 9 Feb 2023 20:59:38 +0000 (12:59 -0800)]
[mlir][Linalg] NFC - Fail gracefully instead of crashing in SplitReduction
Aart Bik [Thu, 9 Feb 2023 20:36:10 +0000 (12:36 -0800)]
[mlir][sparse] fix integration test with "VLA" run
Reviewed By: Peiming
Differential Revision: https://reviews.llvm.org/D143674
Benjamin Kramer [Thu, 9 Feb 2023 20:35:08 +0000 (21:35 +0100)]
Kirill Stoimenov [Thu, 9 Feb 2023 18:23:06 +0000 (18:23 +0000)]
[HWASAN] Add support for max_allocation_size_mb option
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D143667
Fangrui Song [Thu, 9 Feb 2023 20:17:26 +0000 (12:17 -0800)]
[llvm-c-test] Fix leak after D138415
Aart Bik [Thu, 9 Feb 2023 18:53:44 +0000 (10:53 -0800)]
[mlir][memref] annotate operand and result of realloc with proper memory attributes
Reviewed By: springerm
Differential Revision: https://reviews.llvm.org/D143599
Philip Reames [Thu, 9 Feb 2023 19:45:10 +0000 (11:45 -0800)]
[RISCV] Implement a proposed mapping for Ztso
This change implements a proposed lowering from LLVM's memory model to the TSO memory model defined by the Ztso extension. Selecting the proposed mapping turns out to be an involved conversation that really didn't fit within a review description, so let me refer you to https://github.com/preames/public-notes/blob/master/riscv-tso-mappings.rst. This review implements the WMO compatible variant (the proposed one in that document).
Ztso is currently accepted as an experimental extension in LLVM. Despite the fact the extension was recently ratified, I think we need to leave it as experimental until we have wide agreement on the chosen mapping for ABI purposes.
I need to note that the current in-tree implementation defaults to generating WMO compatible fences. This is entirely compatible with the proposed mapping in this patch, but is unfortunately not compatible with the major alternative. The in tree implementation is explicitly experimental so the impact of this is limited, but it is worth calling out that if settle on the alternative we will have a minor ABI break. My apologies for not calling this out in the original patch; I had not realized at the time that one of our realistic choices for mappings wouldn't be WMO compatible.
This patch only contains the changes for load/store and fence. That is, it does not change the lowering for atomicrmw operations. This is a sound thing to do under the proposed mapping since the existing WMO mappings remain compatible. I do plan to change these; I'm just working incrementally.
Differential Revision: https://reviews.llvm.org/D143076
Sacha Ballantyne [Thu, 9 Feb 2023 18:57:04 +0000 (18:57 +0000)]
[Flang] Add Any and All intrinsics to simplify intrinsics pass
This patch provides a simplified version of the Any intrinsic as well as the All intrinsic
that can be used for inlining or simpiler use cases. These changes are targeting exchange2, and
provide a ~9% performance increase.
Reviewed By: Leporacanthicus, vzakhari
Differential Revision: https://reviews.llvm.org/D142977
Ben Langmuir [Wed, 8 Feb 2023 23:34:50 +0000 (15:34 -0800)]
[clang][deps] Migrate ModuleDepCollector to LexedFileChanged NFCI
LexedFileChanged has the semantics we want of ignoring #line/etc. It's
also consistent with other dep collectors like DependencyFileGenerator.
Differential Revision: https://reviews.llvm.org/D143613
duk [Thu, 9 Feb 2023 19:30:19 +0000 (14:30 -0500)]
[MachineOutliner] Make getOutliningType partially target-independent
The motivation behind this patch is to unify some of the outliner logic across architectures. This looks nicer in general and makes fixing [issues like this](https://reviews.llvm.org/D124707#3483805) easier.
There are some notable changes here:
1. `isMetaInstruction()` is used directly instead of checking for specific meta-instructions like `IMPLICIT_DEF` or `KILL`. This was already done in the RISC-V implementation, but other architectures still did hardcoded checks.
- As an exception to this, CFI instructions are explicitly delegated to the target because RISC-V has different handling for those.
2. `isTargetIndex()` checks are replaced with an assert; none of the architectures supported actually use `MO_TargetIndex` at this point in time.
3. `isCFIIndex()` and `isFI()` checks are also replaced with asserts, since these operands should not exist in [any context](https://reviews.llvm.org/D122635#3447214) at this stage in the pipeline.
Reviewed by: paquette
Differential Revision: https://reviews.llvm.org/D125072
Valentin Clement [Thu, 9 Feb 2023 19:30:49 +0000 (20:30 +0100)]
[flang] Fix polymorphic-temp.f90 tests
Valentin Clement [Thu, 9 Feb 2023 19:17:10 +0000 (20:17 +0100)]
[flang] Support polymorphic inputs for TRANSFER intrinsic
Result must carry the polymorphic type information from the mold.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D143651
Krzysztof Drewniak [Mon, 9 Jan 2023 15:56:22 +0000 (15:56 +0000)]
[mlir] Handle different pointer sizes in unranked memref descriptors
The code for unranked memref descriptors assumed that
sizeof(!llvm.ptr) == lizeof(!llvm.ptr<N>) for all address spaces N.
This is not always true (ex. the AMDGPU compiler backend has
sizeof(!llvm.ptr) = 64 bits but sizeof(!llvm.ptr<5>) = 32 bits, where
address space 5 is used for stack allocations). While this is merely
an overallocation in the case where a non-0 address space has pointers
smaller than the default, the existing code could cause OOB memory
accesses when sizeof(!llvm.ptr<N>) > sizeof(!llvm.ptr).
So, add an address spaces parameter to computeSizes in order to
partially resolve this class of bugs. Note that the LLVM data layout
in the conversion passes is currently set to "" and not constructed
from the MLIR data layout or some other source, but this could change
in the future.
Depends on D142159
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D141293
Valentin Clement [Thu, 9 Feb 2023 14:23:48 +0000 (06:23 -0800)]
[flang] Support polymorphic inputs for EOSHIFT intrinsic
Result must carry the polymorphic type information from the array.
Aaron Ballman [Thu, 9 Feb 2023 19:00:58 +0000 (14:00 -0500)]
[libclang] Add "global:" to the module map explicitly; NFC intended
Amir Ayupov [Thu, 9 Feb 2023 18:56:55 +0000 (10:56 -0800)]
[BOLT] Rename BF::isParentFragment -> isChildOf
`isChildOf` is a more concise name for the check. Also, there's no need to
test if the function is a fragment before doing `isChildOf` check.
Reviewed By: #bolt, rafauler, maksfb
Differential Revision: https://reviews.llvm.org/D142667
Amir Ayupov [Thu, 9 Feb 2023 18:54:53 +0000 (10:54 -0800)]
[BOLT][Wrapper] Don't compare output upon error exit code
Fix llvm-bolt-wrapper to skip output file checks if llvm-bolt exits with error
code.
Test Plan:
- checkout to revision with invalid NFC mismatch in `is-strip.s` test
(e.g.
056af487831fb573e6895901d1e48f93922f9635~)
- run `nfc-check-setup.py`
- run `bin/llvm-lit -a tools/bolt/test/X86/is-strip.s`
Reviewed By: #bolt, rafauler
Differential Revision: https://reviews.llvm.org/D143614
Tom Praschan [Sun, 29 Jan 2023 16:02:56 +0000 (17:02 +0100)]
[clangd] Fix getQueryScopes for using-directive with inline namespace
For example, in the following code
```
using namespace std::string_literals;
int main() {
strin^ // Completes `string` instead of `std::string`
}
```
The using declaration would make completion drop the std namespace, even though it shouldn't.
printNamespaceScope() skips inline namespaces, so to fix this use
printQualifiedName() instead
See https://github.com/clangd/clangd/issues/1451
Differential Revision: https://reviews.llvm.org/D140915
Amir Aupov [Thu, 9 Feb 2023 18:52:51 +0000 (10:52 -0800)]
Revert "HHVM calling conventions."
This reverts commit
cce239c45d6ef3865a017b5b3f935964e0348734.
HHVM calling conventions are unused. Remove them by partially reverting the commit.
Reviewed By: MaskRay, MatzeB
Differential Revision: https://reviews.llvm.org/D124330
Fangrui Song [Thu, 9 Feb 2023 18:46:25 +0000 (18:46 +0000)]
[bazel] Fix libc
Jason Molenda [Thu, 9 Feb 2023 18:43:13 +0000 (10:43 -0800)]
Remove test case that tries to allocate impossible amounts
The sanitizer bots are failing with this test; they
impose a maximum 0x10000000000 size on allocations, and
malloc on darwin will let me malloc that much. The
alternative to keep this would be to break it out into a
seperate test in TestProcessAIP and skip that if it's on
the sanitizer, but this is seeming too fragile IMO so I'm
punting it entirely.
Arthur Eubanks [Mon, 6 Feb 2023 21:50:49 +0000 (13:50 -0800)]
[Inliner] Remove legacy simple inliner
It's part of the optimization pipeline, of which the legacy pass manager version is deprecated.
Kiran Chandramohan [Thu, 9 Feb 2023 18:35:38 +0000 (18:35 +0000)]
Revert "[mlir] Add function for checking if a block is inside a loop"
Reverting since the shared library builds are failing.
This reverts commit
dcee187522c6e2e1a56ffc9b58bfe11c6ac44662.
Kiran Chandramohan [Thu, 9 Feb 2023 17:44:49 +0000 (17:44 +0000)]
[Flang][OpenMP] Do not consider procedure names for data-sharing
An incorrect error was issued for procedure names occuring in OpenMP
regions with default clause set to NONE. Fix is to ignore all cases
where names are various kinds of procedures.
Fixes issue https://github.com/flang-compiler/f18-llvm-project/issues/1350
Reviewed By: peixin
Differential Revision: https://reviews.llvm.org/D143384
Florian Mayer [Wed, 8 Feb 2023 02:03:43 +0000 (18:03 -0800)]
[MTE stack] fix incorrect offset for st2g
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D143544
Krzysztof Drewniak [Thu, 19 Jan 2023 21:56:04 +0000 (21:56 +0000)]
Add generic type attribute mapping infrastructure, use it in GpuToX
Remapping memory spaces is a function often needed in type
conversions, most often when going to LLVM or to/from SPIR-V (a future
commit), and it is possible that such remappings may become more
common in the future as dialects take advantage of the more generic
memory space infrastructure.
Currently, memory space remappings are handled by running a
special-purpose conversion pass before the main conversion that
changes the address space attributes. In this commit, this approach is
replaced by adding a notion of type attribute conversions
TypeConverter, which is then used to convert memory space attributes.
Then, we use this infrastructure throughout the *ToLLVM conversions.
This has the advantage of loosing the requirements on the inputs to
those passes from "all address spaces must be integers" to "all
memory spaces must be convertible to integer spaces", a looser
requirement that reduces the coupling between portions of MLIR.
ON top of that, this change leads to the removal of most of the calls
to getMemorySpaceAsInt(), bringing us closer to removing it.
(A rework of the SPIR-V conversions to use this new system will be in
a folowup commit.)
As a note, one long-term motivation for this change is that I would
eventually like to add an allocaMemorySpace key to MLIR data layouts
and then call getMemRefAddressSpace(allocaMemorySpace) in the
relevant *ToLLVM in order to ensure all alloca()s, whether incoming or
produces during the LLVM lowering, have the correct address space for
a given target.
I expect that the type attribute conversion system may be useful in
other contexts.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D142159