Changes

Summary

  1. [clangd] Show parameters for construct. (details)
  2. [Coroutines] Handle InvokeInst in SalvageDebugInfo (details)
  3. [NFC] move GNUELFDumper::printEnum() into a common header for reuse. (details)
  4. [AArch64][NFC] Fix ComplexPattern types conflicting with uses (details)
  5. [AMDGPU][NFC] Alter ComplexPattern types to be consistent with their uses (details)
  6. [AArch64][NFC] Alter ComplexPattern types to be consistent with their uses (details)
  7. [TableGen][SelectionDAG] Use ComplexPattern type for non-leaf nodes (details)
  8. [flang] Return arrays in Transfer runtime with SIZE argument (details)
  9. [mlir][linalg][bufferize] Op interface implementation for Bufferization dialect ops (details)
  10. tsan: disable munmap_invalid.cpp test on darwin (details)
  11. [clangd] IncludeCleaner: Do not require forward declarations of RecordDecls when definition is available (details)
  12. [MemoryLocation] strcat/strncat/strcpy read/write after their args. (details)
  13. [mlir][Vector] Add some missing tests for `broadcast` and `splat` (details)
  14. [mlir][Vector] Support 0-D vectors in `BitCastOp` (details)
  15. [SCEV] Fix ValuesAtScopesUsers consistency (details)
Commit 7bb785cc339b0ea268e388c570c9a0cd78f136c8 by 1585086582
[clangd] Show parameters for construct.

Show parameters for construct.

Reviewed By: kadircet

Differential Revision: https://reviews.llvm.org/D114621
The file was modifiedclang-tools-extra/clangd/Hover.cpp
The file was modifiedclang-tools-extra/clangd/unittests/HoverTests.cpp
Commit 84980761a777619291e4877014c5f00ca512e4b8 by yedeng.yd
[Coroutines] Handle InvokeInst in SalvageDebugInfo

Since coroutine would be splitted into pieces, compiler would move the
dbg.declare intrinsic after the Storage is created to make sure the
corresponding dbg instruction is still available aftet splitted.
However, it would be problematic if the storage instruction is an
InvokeInst, which is a terminator. We couldn't move instruction after an
InvokeInst. This patch tries to move the dbg.declare intrinsic in the
normal destination of the InvokeInst. It should make sense due to the
Storage should be invalid in exception path.
The file was modifiedllvm/test/Transforms/Coroutines/coro-debug.ll
The file was modifiedllvm/lib/Transforms/Coroutines/CoroFrame.cpp
Commit 62c74d496bb40a1845329cece0a38d9267db43c6 by esme.yi
[NFC] move GNUELFDumper::printEnum() into a common header for reuse.

Summary:
This is a NFC patch moving the GNUELFDumper<ELFT>::printEnum()
function from ELFDumper into ScopedPrinter.h for reuse.

Reviewed By: jhenderson

Differential Revision: https://reviews.llvm.org/D114840
The file was modifiedllvm/include/llvm/Support/ScopedPrinter.h
The file was modifiedllvm/tools/llvm-readobj/ELFDumper.cpp
Commit 0cb44cfbb7616e5fb9a0c19c8784cf0fb5cfc2e3 by jrtc27
[AArch64][NFC] Fix ComplexPattern types conflicting with uses

When used as a non-leaf node, TableGen does not currently use the type
of a ComplexPattern for type inference, which also means it does not
check it doesn't conflict with the use. This differs from when used as a
leaf value, where the type is used for inference. Fixing that
discrepancy is something I intend to upstream as a subsequent review,
but these are all the type conflicts found (all legitimate) by my
locally-patched TableGen.

Reviewed By: paulwalker-arm

Differential Revision: https://reviews.llvm.org/D108759
The file was modifiedllvm/lib/Target/AArch64/SVEInstrFormats.td
The file was modifiedllvm/lib/Target/AArch64/AArch64SVEInstrInfo.td
Commit 3ee56eed2fc2c964c203b6e4274da1f32f75d0c0 by jrtc27
[AMDGPU][NFC] Alter ComplexPattern types to be consistent with their uses

When used as a non-leaf node, TableGen does not currently use the type
of a ComplexPattern for type inference, which also means it does not
check it doesn't conflict with the use. This differs from when used as a
leaf value, where the type is used for inference. Fixing that
discrepancy is something I intend to upstream as a subsequent review.

AMDGPU currently has several ComplexPatterns that are used in contexts
where they're expected to be an iPTR, and where using an iPTR instead of
a fixed-width integer type matters. With my locally-patched TableGen,
none of these mismatches result in type contradictions, but do change
the patterns and cause various failures to select. These changes to the
ComplexPatterns' types reflect how they are actually used, result in
bit-for-bit identical TableGen output (without my local TableGen patch),
and ensure that with improved type inference AMDGPU's backend will
continue to work.

Reviewed By: arsenm

Differential Revision: https://reviews.llvm.org/D109032
The file was modifiedllvm/lib/Target/AMDGPU/SMInstructions.td
The file was modifiedllvm/lib/Target/AMDGPU/BUFInstructions.td
The file was modifiedllvm/lib/Target/AMDGPU/FLATInstructions.td
The file was modifiedllvm/lib/Target/AMDGPU/SIInstrInfo.td
Commit a3530dc19980095dca687ea0b660821a67628403 by jrtc27
[AArch64][NFC] Alter ComplexPattern types to be consistent with their uses

When used as a non-leaf node, TableGen does not currently use the type
of a ComplexPattern for type inference, which also means it does not
check it doesn't conflict with the use. This differs from when used as a
leaf value, where the type is used for inference. Fixing that
discrepancy is something I intend to upstream as a subsequent review.

AArch64 currently has several ComplexPatterns that are used in contexts
where they're expected to be an iPTR. The cases that lead to type
contradictions are separated out in D108759, but there are additional
differences to the TableGen output when using my locally-patched
TableGen. None of these appear to matter, at least for passing all the
CodeGen tests, but it's safer to avoid such changes (and similar changes
were causing issues on some AMDGPU tests, causing failures to select).
Changing these additional ComplexPatterns to use iPTR rather than i64
ensures that the TableGen output remains bit-for-bit identical (compared
to without having this patch and my TableGen patch, as well as the
intermediate state of having this patch but not my TableGen patch), and
more accurately captures the higher-level meaning of these patterns.

Reviewed By: david-arm

Differential Revision: https://reviews.llvm.org/D109034
The file was modifiedllvm/lib/Target/AArch64/AArch64InstrFormats.td
The file was modifiedllvm/lib/Target/AArch64/SVEInstrFormats.td
Commit c1048e3eb920958bb48723c5b996f1877554575f by jrtc27
[TableGen][SelectionDAG] Use ComplexPattern type for non-leaf nodes

When used as a non-leaf node, TableGen does not currently use the type
of a ComplexPattern for type inference, which also means it does not
check it doesn't conflict with the use. This differs from when used as a
leaf value, where the type is used for inference. This addresses that
discrepancy. The test case is not representative of most real-world uses
but is sufficient to demonstrate inference is working.

Some of these uses also make use of ValueTypeByHwMode rather than
SimpleValueType and so the existing type inference is extended to
support that alongside the new type inference.

There are also currently various cases of using ComplexPatterns with an
untyped type, but only for non-leaf nodes. For compatibility this is
permitted, and uses the old behaviour of not inferring for non-leaf
nodes, but the existing logic is still used for leaf values. This
remaining discrepancy should eventually be eliminated, either by
removing all such uses of untyped so the special case goes away (I
imagine Any, or a more specific type in certain cases, would be
perfectly sufficient), or by copying it to the leaf value case so
they're consistent with one another if this is something that does need
to keep being supported.

All non-experimental targets have been verified to produce bit-for-bit
identical TableGen output with this change applied.

Reviewed By: kparzysz

Differential Revision: https://reviews.llvm.org/D109035
The file was addedllvm/test/TableGen/dag-isel-complexpattern.td
The file was modifiedllvm/utils/TableGen/CodeGenDAGPatterns.cpp
The file was modifiedllvm/utils/TableGen/CodeGenTarget.h
The file was modifiedllvm/utils/TableGen/CodeGenTarget.cpp
Commit 1c16b0db9d56ba533147cfbe2c4e1bb0a8bcbc45 by jperier
[flang] Return arrays in Transfer runtime with SIZE argument

In TRANSFER runtime the result was an array only if the MOLD was an array.
This is not in line with TRANSFER definition in 16.9.193 that rules that it
must also be an array if MOLD is scalar and SIZE if provided.

Differential Revision: https://reviews.llvm.org/D114943
The file was modifiedflang/unittests/Runtime/MiscIntrinsic.cpp
The file was modifiedflang/runtime/misc-intrinsic.cpp
Commit d30fcadf07ee552f20156ea90be2fdb54cb9cb08 by springerm
[mlir][linalg][bufferize] Op interface implementation for Bufferization dialect ops

This change provides `BufferizableOpInterface` implementations for ops from the Bufferization dialects. These ops are needed at the bufferization boundaries for partial bufferization.

Differential Revision: https://reviews.llvm.org/D114618
The file was modifiedmlir/test/Dialect/Linalg/comprehensive-module-bufferize-analysis.mlir
The file was modifiedutils/bazel/llvm-project-overlay/mlir/BUILD.bazel
The file was addedmlir/include/mlir/Dialect/Linalg/ComprehensiveBufferize/BufferizationInterfaceImpl.h
The file was modifiedmlir/lib/Dialect/Linalg/ComprehensiveBufferize/ComprehensiveBufferize.cpp
The file was modifiedmlir/test/Dialect/Linalg/comprehensive-module-bufferize-invalid.mlir
The file was modifiedmlir/lib/Dialect/Linalg/ComprehensiveBufferize/CMakeLists.txt
The file was modifiedmlir/lib/Dialect/Linalg/ComprehensiveBufferize/BufferizableOpInterface.cpp
The file was addedmlir/lib/Dialect/Linalg/ComprehensiveBufferize/BufferizationInterfaceImpl.cpp
The file was modifiedmlir/lib/Dialect/Linalg/Transforms/ComprehensiveBufferizePass.cpp
Commit 4a5086dce35834bb7143a6b468718974570f0c32 by dvyukov
tsan: disable munmap_invalid.cpp test on darwin

It failed on bots:
https://green.lab.llvm.org/green//job/clang-stage1-RA/25954/consoleFull#-1417328700a1ca8a51-895e-46c6-af87-ce24fa4cd561
and it  doesn't provide the test output.

Reviewed By: melver

Differential Revision: https://reviews.llvm.org/D114972
The file was modifiedcompiler-rt/test/tsan/munmap_invalid.cpp
Commit bab7a30ab692059e5e9dc867a59b9ead47efd35c by kbobyrev
[clangd] IncludeCleaner: Do not require forward declarations of RecordDecls when definition is available

This makes IncludeCleaner more useful in the presense of a large number of
forward declarations. If the definition is already in the Translation Unit and
visible to the Main File, forward declarations have no effect.

The original patch D112707 was split in two: D114864 and this one.

Reviewed By: kadircet

Differential Revision: https://reviews.llvm.org/D114949
The file was modifiedclang-tools-extra/clangd/IncludeCleaner.cpp
The file was modifiedclang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
Commit 829b29b619f3dbbf767833867d027bba23dabb26 by flo
[MemoryLocation] strcat/strncat/strcpy read/write after their args.

strcpy/strcat/strncat access memory starting from the passed in
pointers. Construct memory locations for their args using getAfter.

Discussed in D114872.

Reviewed By: reames

Differential Revision: https://reviews.llvm.org/D114969
The file was modifiedllvm/test/Analysis/BasicAA/libfuncs.ll
The file was modifiedllvm/test/Transforms/DeadStoreElimination/libcalls.ll
The file was modifiedllvm/lib/Analysis/MemoryLocation.cpp
Commit 8e2b3733967296a838ea9861e362fb4d322d165e by nicolas.vasilache
[mlir][Vector] Add some missing tests for `broadcast` and `splat`

Reviewed By: nicolasvasilache

Differential Revision: https://reviews.llvm.org/D114853
The file was modifiedmlir/test/Dialect/Standard/ops.mlir
The file was modifiedmlir/test/Dialect/Vector/ops.mlir
The file was modifiedmlir/test/Dialect/Vector/invalid.mlir
Commit 1423e8bf5dda75877c0414dd26d024fd770d71fb by nicolas.vasilache
[mlir][Vector] Support 0-D vectors in `BitCastOp`

The implementation only allows to bit-cast between two 0-D vectors. We could
probably support casting from/to vectors like `vector<1xf32>`, but I wasn't
convinced that this would be important and it would require breaking the
invariant that `BitCastOp` works only on vectors with equal rank.

Reviewed By: nicolasvasilache

Differential Revision: https://reviews.llvm.org/D114854
The file was modifiedmlir/test/Dialect/Vector/ops.mlir
The file was modifiedmlir/test/Integration/Dialect/Vector/CPU/test-0-d-vectors.mlir
The file was modifiedmlir/include/mlir/Dialect/Vector/VectorOps.td
The file was modifiedmlir/lib/Dialect/Vector/VectorOps.cpp
The file was modifiedmlir/test/Dialect/Vector/invalid.mlir
The file was modifiedmlir/test/Conversion/VectorToLLVM/vector-to-llvm.mlir
The file was modifiedmlir/lib/Conversion/VectorToLLVM/ConvertVectorToLLVM.cpp
Commit 49d040ac978c60d48710d327d5d8b1bd0c9ad1fb by npopov
[SCEV] Fix ValuesAtScopesUsers consistency

Fixes verification failure reported at:
https://reviews.llvm.org/rGc9f9be0381d1

The issue is that getSCEVAtScope() might compute a result without
inserting it in the ValuesAtScopes map in degenerate cases,
specifically if the ValuesAtScopes entry is invalidated during the
calculation. Arguably we should still insert the result if no
existing placeholder is found, but for now just tweak the logic
to only update ValuesAtScopesUsers if ValuesAtScopes is updated.
The file was modifiedllvm/lib/Analysis/ScalarEvolution.cpp
The file was addedllvm/test/Analysis/ScalarEvolution/values-at-scopes-consistency.ll