SuccessChanges

Summary

  1. [LV] Avoid needless fold tail (details)
  2. [Flang][openmp][4/5] Make nowait clause part of OmpClause (details)
  3. [mlir] remove deprecated string-based OpBuilder from ODS (details)
  4. [Flang][openmp][5/5] Make dist_schedule clause part of OmpClause (details)
  5. [llvm][ARM/AArch64] Convert Target Parser CPU tests to fixtures (details)
  6. [lldb/test] Add GdbRemoteTestCaseFactory to avoid duplication in lldb-server tests (details)
  7. [DebugInfo] Don't use DW_OP_implicit_value for fragments (details)
  8. [MachineLICM] Add llvm debug messages to SinkIntoLoop. NFC. (details)
Commit a56280094e08792516b035390a946ea337a27b97 by gil.rapaport
[LV] Avoid needless fold tail

When the trip-count is provably divisible by the maximal/chosen VF, folding the
loop's tail during vectorization is redundant. This commit extends the existing
test for constant trip-counts to any trip-count known to be divisible by
maximal/selected VF by SCEV.

Differential Revision: https://reviews.llvm.org/D93615
The file was addedllvm/test/Transforms/LoopVectorize/dont-fold-tail-for-const-TC.ll
The file was addedllvm/test/Transforms/LoopVectorize/dont-fold-tail-for-divisible-TC.ll
The file was modifiedllvm/lib/Transforms/Vectorize/LoopVectorize.cpp
Commit e282ae57da29a37e143ab6d640f68e794f5cd614 by joshisameeran17
[Flang][openmp][4/5] Make nowait clause part of OmpClause

After discussion in `D93482` we found that the some of the clauses were not
following the common OmpClause convention.

The benefits of using OmpClause:
- Functionalities from structure checker are mostly aligned to work with
  `llvm::omp::Clause`.
- The unparsing as well can take advantage.
- Homogeneity with OpenACC and rest of the clauses in OpenMP.
- Could even generate the parser with TableGen, when there is homogeneity.
- It becomes confusing when to use `flangClass` and `flangClassValue` inside
  TableGen, if incase we generate parser using TableGen we could have only a
  single `let expression`.

This patch makes `OmpNoWait` clause part of `OmpClause`.

Reviewed By: clementval, kiranktp

Differential Revision: https://reviews.llvm.org/D93643
The file was modifiedflang/include/flang/Parser/dump-parse-tree.h
The file was modifiedflang/lib/Parser/openmp-parsers.cpp
The file was modifiedllvm/include/llvm/Frontend/OpenMP/OMP.td
The file was modifiedflang/include/flang/Parser/parse-tree.h
The file was modifiedflang/lib/Semantics/check-omp-structure.h
The file was modifiedflang/lib/Parser/unparse.cpp
The file was modifiedflang/lib/Semantics/check-omp-structure.cpp
Commit 2f5569f6f67a30f7774f7c2d2f3d726752a862ae by zinenko
[mlir] remove deprecated string-based OpBuilder from ODS

It has been deprecated with a warning for two months, removing.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D93623
The file was modifiedmlir/test/mlir-tblgen/op-decl.td
The file was modifiedmlir/tools/mlir-tblgen/OpDefinitionsGen.cpp
The file was modifiedmlir/include/mlir/IR/OpBase.td
Commit 1a6f43991ff7e5249f24660074f0dd784aeecd5f by joshisameeran17
[Flang][openmp][5/5] Make dist_schedule clause part of OmpClause

After discussion in `D93482` we found that the some of the clauses were not
following the common OmpClause convention.

The benefits of using OmpClause:
- Functionalities from structure checker are mostly aligned to work with
  `llvm::omp::Clause`.
- The unparsing as well can take advantage.
- Homogeneity with OpenACC and rest of the clauses in OpenMP.
- Could even generate the parser with TableGen, when there is homogeneity.
- It becomes confusing when to use `flangClass` and `flangClassValue` inside
  TableGen, if incase we generate parser using TableGen we could have only a
  single `let expression`.

This patch makes `OmpDistScheduleClause` clause part of `OmpClause`.
The unparse function for `OmpDistScheduleClause` is adapted since the keyword
and parenthesis are issued by the corresponding unparse function for
`parser::OmpClause::DistSchedule`.

Reviewed By: clementval, kiranktp

Differential Revision: https://reviews.llvm.org/D93644
The file was modifiedflang/include/flang/Parser/parse-tree.h
The file was modifiedflang/lib/Semantics/check-omp-structure.h
The file was modifiedflang/lib/Parser/openmp-parsers.cpp
The file was modifiedflang/lib/Parser/unparse.cpp
The file was modifiedflang/lib/Semantics/check-omp-structure.cpp
The file was modifiedllvm/include/llvm/Frontend/OpenMP/OMP.td
The file was modifiedflang/include/flang/Parser/dump-parse-tree.h
Commit a6783cd7b65d6c739c4dc20ec5191b2e862a4237 by david.spickett
[llvm][ARM/AArch64] Convert Target Parser CPU tests to fixtures

Also convert the test function to use EXPECT_EQ and
remove the special case for the AEK_NONE extension.

This means that each test is marked as failing separatley
and the accumultated EXPECT failures are printed next
to that test, with its parameters.

Before they would be hidden by the "pass &=" pattern
and failures would print in one block since it was a
"single" test.

Example of the new failure messages:
```
ARMCPUTestsPart1/ARMCPUTestFixture.ARMCPUTests/6
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from ARMCPUTestsPart1/ARMCPUTestFixture
[ RUN      ] ARMCPUTestsPart1/ARMCPUTestFixture.ARMCPUTests/6
/work/open_source/nightly-llvm/llvm-project/llvm/unittests/Support/TargetParserTest.cpp:66:
Failure
      Expected: params.ExpectedFlags
      Which is: 3405705229
To be equal to: default_extensions
      Which is: 1
[  FAILED  ] ARMCPUTestsPart1/ARMCPUTestFixture.ARMCPUTests/6, where
GetParam() = "arm8", "armv4", "none", 0xcafef00d, "4" (0 ms)
```

Reviewed By: MarkMurrayARM

Differential Revision: https://reviews.llvm.org/D93392
The file was modifiedllvm/unittests/Support/TargetParserTest.cpp
Commit 0a8a2453fb843cf2e0f43e389b58d516525f0b8c by pavel
[lldb/test] Add GdbRemoteTestCaseFactory to avoid duplication in lldb-server tests

This uses the same approach as the debug info tests to avoid needing to
explicitly spell out the two kinds of tests. I convert a handful of
tests to the new mechanism. The rest will be converted in follow-up
patches.
The file was modifiedlldb/test/API/tools/lldb-server/TestGdbRemoteKill.py
The file was modifiedlldb/test/API/tools/lldb-server/TestGdbRemoteProcessInfo.py
The file was modifiedlldb/test/API/tools/lldb-server/TestGdbRemoteModuleInfo.py
The file was modifiedlldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
The file was modifiedlldb/test/API/tools/lldb-server/TestGdbRemoteSingleStep.py
The file was modifiedlldb/test/API/tools/lldb-server/TestGdbRemoteThreadsInStopReply.py
The file was modifiedlldb/test/API/tools/lldb-server/TestGdbRemoteExitCode.py
The file was modifiedlldb/test/API/tools/lldb-server/TestGdbRemoteRegisterState.py
The file was modifiedlldb/packages/Python/lldbsuite/test/decorators.py
Commit 8d75d902a955602feb7e2501e34f814ff5630415 by pavel
[DebugInfo] Don't use DW_OP_implicit_value for fragments

Currently using DW_OP_implicit_value in fragments produces invalid DWARF
expressions. (Such a case can occur in complex floats, for example.)

This problem manifests itself as a missing DW_OP_piece operation after
the last fragment. This happens because the function for printing
constant float value skips printing the accompanying DWARF expression,
as that would also print DW_OP_stack_value (which is not desirable in
this case). However, this also results in DW_OP_piece being skipped.

The reason that DW_OP_piece is missing only for the last piece is that
the act of printing the next fragment corrects this. However, it does
that for the wrong reason -- the code emitting this DW_OP_piece thinks
that the previous fragment was missing, and so it thinks that it needs
to skip over it in order to be able to print itself.

In a simple scenario this works out, but it's likely that in a more
complex setup (where some pieces are in fact missing), this logic would
go badly wrong. In a simple setup gdb also seems to not mind the fact
that the DW_OP_piece is missing, but it would also likely not handle
more complex use cases.

For this reason, this patch disables the usage of DW_OP_implicit_value
in the frament scenario (we will use DW_OP_const*** instead), until we
figure out the right way to deal with this. This guarantees that we
produce valid expressions, and gdb can handle both kinds of inputs
anyway.

Differential Revision: https://reviews.llvm.org/D92013
The file was modifiedllvm/test/DebugInfo/X86/implicit_value-double.ll
The file was modifiedllvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
Commit 9a6de74d5a9e11a7865ce4873ff3297b7efbb673 by sjoerd.meijer
[MachineLICM] Add llvm debug messages to SinkIntoLoop. NFC.

I am investigating sinking instructions back into the loop under high
register pressure. This is just a first NFC step to add some debug
messages that allows tracing of the decision making.
The file was modifiedllvm/lib/CodeGen/MachineLICM.cpp