AbortedChanges

Summary

  1. [lldb] Error when there are no ports to launch a gdbserver on (details)
  2. [NFC][clang-tidy] Do link FrontendOpenMP into concurrency module after all (details)
  3. [LegacyPM] Simplify PMTopLevelManager::collectLastUses. NFC. (details)
  4. Add `using ConvertToLLVMPattern::match/matchAndRewrite` to avoid 'hiding overload' warning. (details)
  5. [X86][AVX512] Only lower to VPALIGNR if we have BWI (PR48322) (details)
  6. [lldb] Use llvm::Optional for port in LaunchGDBServer (details)
  7. [AArch64][CostModel] Fix cost for mul <2 x i64> (details)
Commit 98e87f76d0f486122d76b334232102e0d7a9254d by david.spickett
[lldb] Error when there are no ports to launch a gdbserver on

Previously if you did:
$ lldb-server platform --server <...> --min-gdbserver-port 12346
--max-gdbserver-port 12347
(meaning only use port 12346 for gdbservers)

Then tried to launch two gdbservers on the same connection,
the second one would return port 65535. Which is a real port
number but it actually means lldb-server didn't find one it was
allowed to use.

send packet: $qLaunchGDBServer;<...>
read packet: $pid:1919;port:12346;#c0
<...>
send packet: $qLaunchGDBServer;<...>
read packet: $pid:1927;port:65535;#c7

This situation should be an error even if port 65535 does happen
to be available on the current machine.

To fix this make PortMap it's own class within
GDBRemoteCommunicationServerPlatform.

This almost the same as the old typedef but for
GetNextAvailablePort() returning an llvm::Expected.
This means we have to handle not finding a port,
by returning an error packet.

Also add unit tests for this new PortMap class.

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D91634
The file was modifiedlldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerPlatform.cpp
The file was modifiedlldb/tools/lldb-server/lldb-platform.cpp
The file was modifiedlldb/unittests/Process/gdb-remote/CMakeLists.txt
The file was modifiedlldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.h
The file was addedlldb/unittests/Process/gdb-remote/PortMapTest.cpp
The file was modifiedlldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerPlatform.h
Commit 317ca3ecf8244cabb4ca9d45e626ad3cf0f8e4b2 by lebedev.ri
[NFC][clang-tidy] Do link FrontendOpenMP into concurrency module after all

It seems that while clangASTMatchers does add FrontendOpenMP into
it's LLVM_LINK_COMPONENTS, it's still not being propagated transitively.
The file was modifiedclang-tools-extra/clang-tidy/concurrency/CMakeLists.txt
Commit e20efa3dd5c75a79a47d40335aee0f63261f9c5b by jay.foad
[LegacyPM] Simplify PMTopLevelManager::collectLastUses. NFC.
The file was modifiedllvm/lib/IR/LegacyPassManager.cpp
Commit ffaba24c75edc274ec651915a0f2f500b8f6b341 by csigg
Add `using ConvertToLLVMPattern::match/matchAndRewrite` to avoid 'hiding overload' warning.

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D92303
The file was modifiedmlir/include/mlir/Conversion/StandardToLLVM/ConvertStandardToLLVM.h
Commit 83d79ca5bf13ca37f4ab69f24004ca83c1d03ea4 by llvm-dev
[X86][AVX512] Only lower to VPALIGNR if we have BWI (PR48322)
The file was modifiedllvm/lib/Target/X86/X86ISelLowering.cpp
The file was modifiedllvm/test/CodeGen/X86/vector-shuffle-512-v16.ll
Commit a7f8d96b16a394a87230d592c727906f67a4ba07 by david.spickett
[lldb] Use llvm::Optional for port in LaunchGDBServer

Previously we used UINT16_MAX to mean no port/no specifc
port. This leads to confusion because 65535 is a valid
port number.

Instead use an optional. If you want a specific port call
LaunchGDBServer as normal, otherwise pass an empty optional
and it will be set to the port that gets chosen.
(or left empty in the case where we fail to find a port)

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D92035
The file was modifiedlldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerPlatform.cpp
The file was modifiedlldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerPlatform.h
The file was modifiedlldb/tools/lldb-server/lldb-platform.cpp
Commit 5110ff08176f29eefd7638e328d65dfd1c1ad042 by sjoerd.meijer
[AArch64][CostModel] Fix cost for mul <2 x i64>

This was modeled to have a cost of 1, but since we do not have a MUL.2d this is
scalarized into vector inserts/extracts and scalar muls.

Motivating precommitted test is test/Transforms/SLPVectorizer/AArch64/mul.ll,
which we don't want to SLP vectorize.

Test Transforms/LoopVectorize/AArch64/extractvalue-no-scalarization-required.ll
unfortunately needed changing, but the reason is documented in
LoopVectorize.cpp:6855:

  // The cost of executing VF copies of the scalar instruction. This opcode
  // is unknown. Assume that it is the same as 'mul'.

which I will address next as a follow up of this.

Differential Revision: https://reviews.llvm.org/D92208
The file was modifiedllvm/test/Analysis/CostModel/AArch64/mul.ll
The file was modifiedllvm/test/Transforms/SLPVectorizer/AArch64/mul.ll
The file was modifiedllvm/lib/Target/AArch64/AArch64TargetTransformInfo.cpp
The file was modifiedllvm/test/Transforms/LoopVectorize/AArch64/extractvalue-no-scalarization-required.ll