Changes from Git (git http://labmaster3.local/git/llvm-project.git)


  1. [mlir] Add populateGpuToLLVMConversionPatterns function (details)
  2. [mlir] Change ABI breaking use of NDEBUG to LLVM_ENABLE_ABI_BREAKING_CHECKS (details)
  3. [Analysis] Remove unused declaration isGEPBaseAtNegativeOffset (NFC) (details)
  4. [InstCombine] Precommit tests for D106872 (NFC) (details)
  5. [lldb] Avoid moving ThreadPlanSP from plans vector (details)
  6. [clang-repl] Fix building with win32 dylibs (details)
Commit 7d855605830f4a524f02b09d6891b351ff716782 by ivan.butygin
[mlir] Add populateGpuToLLVMConversionPatterns function

Differential Revision:
The file was modifiedmlir/include/mlir/Conversion/GPUCommon/GPUCommonPass.h
The file was modifiedmlir/lib/Conversion/GPUCommon/GPUToLLVMConversion.cpp
Commit 97335ad13fd4f231a75163a1e5c232aed5efe921 by markus.boeck02
[mlir] Change ABI breaking use of NDEBUG to LLVM_ENABLE_ABI_BREAKING_CHECKS

The `DataLayout` class currently contains the member `layoutStack` which is hidden behind a preprocessor region dependant on the NDEBUG macro. Code wise this makes a lot of sense, as the `layoutStack` is used for extra assertions that users will want when compiling a debug build.
It however has the uncomfortable consequence of leading to a different ABI in Debug and Release builds. This I think is a bit annoying for downstream projects and others as they may want to build against a stable Release of MLIR in Release mode, but be able to debug their own project depending on MLIR.

This patch changes the related uses of NDEBUG to LLVM_ENABLE_ABI_BREAKING_CHECKS. As the macro is computed at configure time of LLVM, it may not change based on compiler settings of a downstream projects like NDEBUG would.

Differential Revision:
The file was modifiedmlir/lib/Interfaces/DataLayoutInterfaces.cpp
The file was modifiedmlir/include/mlir/Interfaces/DataLayoutInterfaces.h
Commit ea155b995c98f821471516f9f6ae62c32c4d23b2 by kazu
[Analysis] Remove unused declaration isGEPBaseAtNegativeOffset (NFC)

The corresponding function definition was removed on Mar 3, 2021 in
commit ea7d208b780657c236986d7dfd7ba577583fd99a.
The file was modifiedllvm/include/llvm/Analysis/BasicAliasAnalysis.h
Commit 56e7b6c3924d7ba8db70c38235a77ed8208795eb by krishna17060
[InstCombine] Precommit tests for D106872 (NFC)
The file was modifiedllvm/test/Transforms/InstCombine/fabs.ll
Commit 41d0b20cc90f2aea25b4306f6c8f6c258ca3d377 by
[lldb] Avoid moving ThreadPlanSP from plans vector

Change `ThreadPlanStack::PopPlan` and `::DiscardPlan` to not do the following:

1. Move the last plan, leaving a moved `ThreadPlanSP` in the plans vector
2. Operate on the last plan
3. Pop the last plan off the plans vector

This leaves a period of time where the last element in the plans vector has been moved. I am not sure what, if any, guarantees there are when doing this, but it seems like it would/could leave a null `ThreadPlanSP` in the container. There are asserts in place to prevent empty/null `ThreadPlanSP` instances from being pushed on to the stack, and so this could break that invariant during multithreaded access to the thread plan stack.

An open question is whether this use of `std::move` was the result of a measure performance problem.

Differential Revision:
The file was modifiedlldb/include/lldb/Target/ThreadPlan.h
The file was modifiedlldb/source/Target/ThreadPlanCallUserExpression.cpp
The file was modifiedlldb/source/Target/ThreadPlanStepOverBreakpoint.cpp
The file was modifiedlldb/include/lldb/Target/ThreadPlanCallUserExpression.h
The file was modifiedlldb/source/Target/ThreadPlanStack.cpp
The file was modifiedlldb/include/lldb/Target/ThreadPlanStepOverBreakpoint.h
The file was modifiedlldb/include/lldb/Target/ThreadPlanCallFunction.h
The file was modifiedlldb/source/Target/ThreadPlan.cpp
The file was modifiedlldb/source/Target/ThreadPlanCallFunction.cpp
Commit 25a288b009f7d30b5392ea36c29570cbdcf238c3 by martin
[clang-repl] Fix building with win32 dylibs

Use `clang_target_link_libraries` to avoid duplicate libraries when
the same symbol is provided both by a static library and a larger
dylib, fixing linking with win32 dylibs. This fixes errors like

    ld.lld: error: duplicate symbol: llvm::createStringError(std::__1::error_code, char const*)
    >>> defined at libLLVMSupport.a(Error.cpp.obj)
    >>> defined at libLLVM-14git.dll

This matches how other clang tools declare their dependencies.

Differential Revision:
The file was modifiedclang/tools/clang-repl/CMakeLists.txt