SuccessChanges

Summary

  1. [lldb-vscode] only report long running progress events (details)
  2. [lldb-vscode] Add simple DAP logs dump to investigate flakiness in tests (details)
  3. Revert "[lldb-vscode] only report long running progress events" (details)
  4. [mlir][linalg] Fusion of PadTensorOp (details)
  5. Retry of [lldb-vscode] only report long running progress events (details)
  6. [WebAssembly] Make tag attribute's encoding uint8 (details)
  7. [LoopDeletion] Require loop to have a predecessor when executing 1st iteration symbolically (details)
  8. Re-land "[LoopDeletion] Handle Phis with similar inputs from different blocks" (details)
Commit 610d474cfd82f11dc4702e2cf1b2485584d7c243 by walter erquinigo
[lldb-vscode] only report long running progress events

When the number of shared libs is massive, there could be hundreds of
thousands of short lived progress events sent to the IDE, which makes it
irresponsive while it's processing all this data. As these small jobs
take less than a second to process, the user doesn't even see them,
because the IDE only display the progress of long operations. So it's
better not to send these events.

I'm fixing that by sending only the events that are taking longer than 5
seconds to process.
In a specific run, I got the number of events from ~500k to 100, because
there was only 1 big lib to parse.

I've tried this on several small and massive targets, and it seems to
work fine.

Differential Revision: https://reviews.llvm.org/D101128
The file was modifiedlldb/tools/lldb-vscode/ProgressEvent.cpp
The file was modifiedlldb/tools/lldb-vscode/VSCode.cpp
The file was modifiedlldb/tools/lldb-vscode/VSCode.h
The file was modifiedlldb/tools/lldb-vscode/ProgressEvent.h
The file was modifiedlldb/tools/lldb-vscode/lldb-vscode.cpp
Commit 2e11f4e06804e53cee95e63fdc9e5152f8444abb by walter erquinigo
[lldb-vscode] Add simple DAP logs dump to investigate flakiness in tests

A few times tests have been flaky, presumably by crashed of lldb-vscode
itself. They can be caught by looking at the DAP logs, so I'm dumping
them when the session ends.
The file was modifiedlldb/packages/Python/lldbsuite/test/tools/lldb-vscode/vscode.py
Commit f84615a5a5cb05aacdb0e9e7ab13f3b95ce11ece by walter erquinigo
Revert "[lldb-vscode] only report long running progress events"

This reverts commit 610d474cfd82f11dc4702e2cf1b2485584d7c243.

lldb-vscode is crashing.
The file was modifiedlldb/tools/lldb-vscode/ProgressEvent.h
The file was modifiedlldb/tools/lldb-vscode/lldb-vscode.cpp
The file was modifiedlldb/tools/lldb-vscode/VSCode.h
The file was modifiedlldb/tools/lldb-vscode/ProgressEvent.cpp
The file was modifiedlldb/tools/lldb-vscode/VSCode.cpp
Commit 2ba387a316d1bd3b81b4eac00418e903f5c421cd by springerm
[mlir][linalg] Fusion of PadTensorOp

Note: This commit (and previous ones) implements the same functionality as https://reviews.llvm.org/D103243 (which is abandoned).

Differential Revision: https://reviews.llvm.org/D104683
The file was modifiedmlir/test/lib/Dialect/Linalg/TestLinalgFusionTransforms.cpp
The file was modifiedmlir/test/Dialect/Linalg/tile-and-fuse-tensors.mlir
The file was modifiedmlir/lib/Dialect/Linalg/Transforms/Transforms.cpp
Commit bff2b9adbc8de23aeaa654c5957624078ddf8fe9 by walter erquinigo
Retry of [lldb-vscode] only report long running progress events

This time adding a check that should prevent the crash found in
https://lab.llvm.org/buildbot/#/builders/68/builds/14182/steps/6/logs/stdio

Differential Revision: https://reviews.llvm.org/D101128
The file was modifiedlldb/tools/lldb-vscode/VSCode.h
The file was modifiedlldb/tools/lldb-vscode/ProgressEvent.cpp
The file was modifiedlldb/tools/lldb-vscode/ProgressEvent.h
The file was modifiedlldb/tools/lldb-vscode/VSCode.cpp
The file was modifiedlldb/tools/lldb-vscode/lldb-vscode.cpp
Commit 1c7b84108861ac92fb353891e7e4c747b6ea9f28 by aheejin
[WebAssembly] Make tag attribute's encoding uint8

This changes the encoding of the `attribute` field, which currently only
contains the value `0` denoting this tag is for an exception, from
`varuint32` to `uint8`. This field is effectively unused at the moment
and reserved for future use, and it is not likely to need `varuint32`
even in future.
See https://github.com/WebAssembly/exception-handling/pull/162.

This does not change any encoded binaries because `0` is encoded in the
same way both in `varuint32` and `uint8`.

Reviewed By: tlively

Differential Revision: https://reviews.llvm.org/D104571
The file was modifiedllvm/lib/MC/WasmObjectWriter.cpp
The file was modifiedllvm/include/llvm/BinaryFormat/Wasm.h
The file was modifiedllvm/lib/Object/WasmObjectFile.cpp
Commit 575253887bccb8732b901608dabcec3d60324cf0 by mkazantsev
[LoopDeletion] Require loop to have a predecessor when executing 1st iteration symbolically

Two predecessors break the further logic, and the loop may come to the
opt in non-canonicalized state.
The file was addedllvm/test/Transforms/LoopDeletion/two-predecessors.ll
The file was modifiedllvm/lib/Transforms/Scalar/LoopDeletion.cpp
Commit 4c4f1ae93ea7477ccb4772007fc78313f5a0644f by mkazantsev
Re-land "[LoopDeletion] Handle Phis with similar inputs from different blocks"

Patch was reverted due to a bug that existed before it and was exposed
by it. Returning after the underlying bug has been fixed.

Differential Revision: https://reviews.llvm.org/D103959
The file was modifiedllvm/lib/Transforms/Scalar/LoopDeletion.cpp
The file was modifiedllvm/test/Transforms/LoopDeletion/eval_first_iteration.ll