SuccessChanges

Summary

  1. [gn build] Port bbb3d03f93b8 (details)
  2. Move code for checking loop metadata into Analysis [nfc] (details)
  3. Move variable only used inside an assert into the assert. (details)
  4. [SCEV] Use mustprogress flag on loops (in addition to function attribute) (details)
  5. [ELF][RISCV] Resolve branch relocations referencing undefined weak to current location if not using PLT (details)
  6. [ELF] Simplify getAArch64UndefinedRelativeWeakVA. NFC (details)
  7. [libc++] Remove unnecessary header in enable_view.h (which caused a cycle) (details)
  8. [LI] Add a cover function for checking if a loop is mustprogress [nfc] (details)
  9. [ARM] Fix Changed status in MVEGatherScatterLoweringPass. (details)
  10. [clang] NRVO: Improvements and handling of more cases. (details)
  11. [SimplifyCFG] avoid 'tmp' variables in test file; NFC (details)
  12. [LV] Parallel annotated loop does not imply all loads can be hoisted. (details)
  13. 2d Arm Neon sdot op, and lowering to the intrinsic. (details)
  14. [MLIR] Document that Dialect Conversion traverses in preorder (details)
Commit 14097fbb0818dab80676c0cd909116b1720f2c9f by llvmgnsyncbot
[gn build] Port bbb3d03f93b8
The file was modifiedllvm/utils/gn/secondary/libcxx/include/BUILD.gn
Commit b6ee5f2b1df66987e65e1b636ba9ae1554b0334b by listmail
Move code for checking loop metadata into Analysis [nfc]

I need the mustprogress loop metadata in ScalarEvolution and it makes sense to keep all the accessors for quering loop metadate together.
The file was modifiedllvm/include/llvm/Transforms/Utils/LoopUtils.h
The file was modifiedllvm/include/llvm/Analysis/LoopInfo.h
The file was modifiedllvm/lib/Analysis/LoopInfo.cpp
The file was modifiedllvm/lib/Transforms/Utils/LoopUtils.cpp
Commit 1d3873d41eca67e974bafbaa91866581bcc0d973 by saugustine
Move variable only used inside an assert into the assert.

This prevents build failures with -Wunused.
The file was modifiedclang/lib/Serialization/ASTReaderStmt.cpp
Commit aaaeb4b160fe94e0ad3bcd6073eea4807f84a33a by listmail
[SCEV] Use mustprogress flag on loops (in addition to function attribute)

This addresses a performance regression reported against 3c6e4191.  That change (correctly) limited a transform based on assumed finiteness to mustprogress loops, but the previous change (38540d7) which introduced the mustprogress check utility only handled function attributes, not the loop metadata form.

It turns out that clang uses the function attribute form for C++, and the loop metadata form for C.  As a result, 3c6e4191 ended up being a large regression in practice for C code as loops weren't being considered mustprogress despite the language semantics.
The file was modifiedllvm/test/Analysis/ScalarEvolution/trip-count-unknown-stride.ll
The file was modifiedllvm/lib/Analysis/ScalarEvolution.cpp
Commit c03b6305d8419fda84a67f4fe357b69a86e4b54f by i
[ELF][RISCV] Resolve branch relocations referencing undefined weak to current location if not using PLT

In a -no-pie link we optimize R_PLT_PC to R_PC. Currently we resolve a branch
relocation to the link-time zero address. However such a choice tends to cause
relocation overflow possibility for RISC architectures.

* aarch64: GNU ld: rewrite the instruction to a NOP; ld.lld: branch to the next instruction
* mips: GNU ld: branch to the start of the text segment (?); ld.lld: branch to zero
* ppc32: GNU ld: rewrite the instruction to a NOP; ld.lld: branch to the current instruction
* ppc64: GNU ld: rewrite the instruction to a NOP; ld.lld: branch to the current instruction
* riscv: GNU ld: branch to the absolute zero address (with instruction rewriting)
* i386/x86_64: GNU ld/ld.lld: branch to the link-time zero address

I think that resolving to the same location is a good choice. The instruction,
if triggered, is clearly an undefined behavior. Resolving to the same location
can cause an infinite loop (making the user aware of the issue) while ensuring
no overflow.

Reviewed By: jrtc27

Differential Revision: https://reviews.llvm.org/D103001
The file was modifiedlld/ELF/InputSection.cpp
The file was modifiedlld/test/ELF/riscv-undefined-weak.s
Commit 0995bbdb66ebd91097c344dfc6529cd05de4818d by i
[ELF] Simplify getAArch64UndefinedRelativeWeakVA. NFC
The file was modifiedlld/ELF/InputSection.cpp
Commit 859c924c5fd58865e824b02c8bea40e7cb55456e by Louis Dionne
[libc++] Remove unnecessary header in enable_view.h (which caused a cycle)
The file was modifiedlibcxx/include/__ranges/enable_view.h
Commit 7629b2a09c169bfd7f7295deb3678f3fa7755eee by listmail
[LI] Add a cover function for checking if a loop is mustprogress [nfc]

Essentially, the cover function simply combines the loop level check and the function level scope into one call.  This simplifies several callers and is (subjectively) less error prone.
The file was modifiedllvm/lib/Analysis/ScalarEvolution.cpp
The file was modifiedllvm/include/llvm/Analysis/LoopInfo.h
The file was modifiedllvm/lib/Analysis/LoopInfo.cpp
The file was modifiedllvm/lib/Transforms/Utils/LoopUtils.cpp
The file was modifiedllvm/lib/Transforms/Scalar/LoopIdiomRecognize.cpp
Commit 5d5b686f6bf6b15b8fbd9ccf957295397f27afc9 by david.green
[ARM] Fix Changed status in MVEGatherScatterLoweringPass.

Now that we are calling SimplifyInstructionsInBlock, make sure we update
Changed when it reports alterations.
The file was modifiedllvm/lib/Target/ARM/MVEGatherScatterLowering.cpp
Commit 667fbcdd0b2ee5e78f5ce9789b862e3bbca94644 by mizvekov
[clang] NRVO: Improvements and handling of more cases.

This expands NRVO propagation for more cases:

Parse analysis improvement:
* Lambdas and Blocks with dependent return type can have their variables
  marked as NRVO Candidates.

Variable instantiation improvements:
* Fixes crash when instantiating NRVO variables in Blocks.
* Functions, Lambdas, and Blocks which have auto return type have their
  variables' NRVO status propagated. For Blocks with non-auto return type,
  as a limitation, this propagation does not consider the actual return
  type.

This also implements exclusion of VarDecls which are references to
dependent types.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

Reviewed By: Quuxplusone

Differential Revision: https://reviews.llvm.org/D99696
The file was modifiedclang/lib/Sema/SemaCoroutine.cpp
The file was modifiedclang/lib/Sema/SemaTemplateInstantiateDecl.cpp
The file was modifiedclang/include/clang/Sema/Sema.h
The file was modifiedclang/lib/Sema/SemaExprCXX.cpp
The file was modifiedclang/lib/Sema/Sema.cpp
The file was modifiedclang/lib/Sema/SemaStmt.cpp
The file was modifiedclang/test/CodeGen/nrvo-tracking.cpp
Commit 7b969ef8b4eb93d7a2be093b27280f12b8cd9ccb by spatel
[SimplifyCFG] avoid 'tmp' variables in test file; NFC
The file was modifiedllvm/test/Transforms/SimplifyCFG/two-entry-phi-return.ll
Commit 4f01122c3f6c70beee8f736f196a09976602685f by joachim
[LV] Parallel annotated loop does not imply all loads can be hoisted.

As noted in https://bugs.llvm.org/show_bug.cgi?id=46666, the current behavior of assuming if-conversion safety if a loop is annotated parallel (`!llvm.loop.parallel_accesses`), is not expectable, the documentation for this behavior was since removed from the LangRef again, and can lead to invalid reads.
This was observed in POCL (https://github.com/pocl/pocl/issues/757) and would require similar workarounds in current work at hipSYCL.

The question remains why this was initially added and what the implications of removing this optimization would be.
Do we need an alternative mechanism to propagate the information about legality of if-conversion?
Or is the idea that conditional loads in `#pragma clang loop vectorize(assume_safety)` can be executed unmasked without additional checks flawed in general?
I think this implication is not part of what a user of that pragma (and corresponding metadata) would expect and thus dangerous.

Only two additional tests failed, which are adapted in this patch. Depending on the further direction force-ifcvt.ll should be removed or further adapted.

Reviewed By: jdoerfert

Differential Revision: https://reviews.llvm.org/D103907
The file was modifiedllvm/include/llvm/Transforms/Vectorize/LoopVectorizationLegality.h
The file was removedllvm/test/Transforms/LoopVectorize/X86/force-ifcvt.ll
The file was modifiedllvm/lib/Transforms/Vectorize/LoopVectorizationLegality.cpp
The file was modifiedllvm/test/Transforms/LoopVectorize/X86/tail_folding_and_assume_safety.ll
Commit 20daedacca803b81db6d8773b705345702bf0fc3 by ataei
2d Arm Neon sdot op, and lowering to the intrinsic.

This adds Sdot2d op, which is similar to the usual Neon
intrinsic except that it takes 2d vector operands, reflecting the
structure of the arithmetic that it's performing: 4 separate
4-dimensional dot products, whence the vector<4x4xi8> shape.

This also adds a new pass, arm-neon-2d-to-intr, lowering
this new 2d op to the 1d intrinsic.

Reviewed By: nicolasvasilache

Differential Revision: https://reviews.llvm.org/D102504
The file was addedmlir/test/Dialect/ArmNeon/invalid.mlir
The file was modifiedmlir/lib/Conversion/CMakeLists.txt
The file was modifiedmlir/include/mlir/Conversion/Passes.td
The file was modifiedmlir/include/mlir/Dialect/ArmNeon/ArmNeon.td
The file was modifiedmlir/lib/Conversion/PassDetail.h
The file was addedmlir/lib/Conversion/ArmNeon2dToIntr/CMakeLists.txt
The file was addedmlir/lib/Conversion/ArmNeon2dToIntr/ArmNeon2dToIntr.cpp
The file was addedmlir/include/mlir/Conversion/ArmNeon2dToIntr/ArmNeon2dToIntr.h
The file was modifiedmlir/include/mlir/Conversion/Passes.h
The file was addedmlir/test/Target/LLVMIR/arm-neon-2d.mlir
Commit 4f6ec382c8b7204f3b1f48060025f970925f5804 by gcmn
[MLIR] Document that Dialect Conversion traverses in preorder

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D102525
The file was modifiedmlir/docs/DialectConversion.md