SuccessChanges

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

Summary

  1. DebugInfo: Reduce long-distance dependence on what will/won't emit a debug_addr section (details)
  2. [InstCombine] visitMaskedMerge(): when unfolding, sanitize undef constants (PR45955) (details)
  3. [Alignment] Remove unnecessary getValueOrABITypeAlignment calls (NFC) (details)
  4. [MLIR][cmake][NFC] Update linkage checker for mlir-opt (details)
  5. [MLIR] Fix linkage for libMLIR.so (details)
Commit a055e3856f813f73d82e992cfe78dcdb918a39c5 by dblaikie
DebugInfo: Reduce long-distance dependence on what will/won't emit a debug_addr section

This is a no-op/NFC at the moment & generally makes the code /somewhat/
cleaner/less reliant on assumptions about what will produce a debug_addr
section.

It's still a bit "spooky action at a distance" - the add ranges code
pre-emptively inserts addresses into the address pool it knows will
eventually be used by the range emission code (or low/high pc).

The 'ideal' would be either to actually compute the addresses needed for
range (& loc) emission earlier - which would mean decanonicalizing the
range/loc representation earlier to account for whether it was going to
use addrx encodings or not (which would be unfortunate, but could be
refactored to be relatively unobtrusive).

Alternatively, emitting the range/loc sections earlier would cause them
to request the needed addresses sooner - but then you endup having to
split finalizeModuleInfo because some things need to be handled there
before the ranges/locs are emitted, I think...
The file was modifiedllvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
Commit fde8eb00e1466cecd0fc6697f8c2ab837c5b7cf3 by lebedev.ri
[InstCombine] visitMaskedMerge(): when unfolding, sanitize undef constants (PR45955)

We can't leave undef vector element constants as-is,
it is a miscompile, so we need to sanitize them.

We have two vectors (C and ~C):
* We can't replace undef with 0 in both of them
* We can't replace undef with 0 in only one of them
* We could replace undef with -1 in both of them
* We could replace undef with -1 in only one(!) of them
* We could replace undef with -1 in one and 0 in another one of them.

Therefore, it seems best to go with the last option, since otherwise
we'd loose knowledge that C and ~C have no common bits set,
which seems more important than preserving partial undef knowledge.

Fixes https://bugs.llvm.org/show_bug.cgi?id=45955
The file was modifiedllvm/test/Transforms/InstCombine/unfold-masked-merge-with-const-mask-vector.ll
The file was modifiedllvm/lib/Transforms/InstCombine/InstCombineAndOrXor.cpp
Commit 52e98f620caf29f75c6d41f51a45610c26f68c65 by nikita.ppv
[Alignment] Remove unnecessary getValueOrABITypeAlignment calls (NFC)

Now that load/store alignment is required, we no longer need most
of them. Also switch the getLoadStoreAlignment() helper to return
Align instead of MaybeAlign.
The file was modifiedllvm/lib/Analysis/VectorUtils.cpp
The file was modifiedllvm/lib/Transforms/Vectorize/LoopVectorize.cpp
The file was modifiedllvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
The file was modifiedllvm/lib/Transforms/Scalar/SROA.cpp
The file was modifiedllvm/lib/CodeGen/GlobalISel/IRTranslator.cpp
The file was modifiedllvm/lib/Transforms/Instrumentation/DataFlowSanitizer.cpp
The file was modifiedllvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
The file was modifiedllvm/include/llvm/IR/Instructions.h
The file was modifiedllvm/lib/Transforms/Scalar/AlignmentFromAssumptions.cpp
The file was modifiedllvm/lib/Transforms/Vectorize/LoopVectorizationLegality.cpp
The file was modifiedllvm/lib/Transforms/Vectorize/LoadStoreVectorizer.cpp
The file was modifiedllvm/lib/Target/X86/X86FastISel.cpp
The file was modifiedllvm/lib/Transforms/Scalar/MemCpyOptimizer.cpp
The file was modifiedllvm/lib/Analysis/Loads.cpp
Commit f88c7fe46b37960599e15d373e6ebb0cb2efdc01 by stephen.neuendorffer
[MLIR][cmake][NFC] Update linkage checker for mlir-opt

New CMakeLists.txt for MLIRStandardOpsTransforms was incorrect, but wasn't
caught by the check.

Differential Revision: https://reviews.llvm.org/D80075
The file was modifiedmlir/tools/mlir-opt/CMakeLists.txt
The file was modifiedmlir/cmake/modules/AddMLIR.cmake
Commit 37ce8d6ade24b2fb9f332b5ff94c25b40f1fc701 by stephen.neuendorffer
[MLIR] Fix linkage for libMLIR.so

Generally:
1) don't use target_link_libraries() and add_mlir_library() on the same target, use LINK_LIBS PUBLIC instead.
2) don't use LINK_LIBS to specify LLVM libraries.  Use LINK_COMPONENTS instead
3) no need to link against LLVMSupport.  We pull it in by default.

Differential Revision: https://reviews.llvm.org/D80076
The file was modifiedmlir/lib/Dialect/StandardOps/Transforms/CMakeLists.txt
The file was modifiedmlir/lib/IR/CMakeLists.txt
The file was modifiedmlir/lib/Support/CMakeLists.txt
The file was modifiedmlir/lib/Conversion/LinalgToStandard/CMakeLists.txt
The file was modifiedmlir/lib/ExecutionEngine/CMakeLists.txt