FailedChanges

Summary

  1. Fix llvm::Optional build breaks in MSVC using std::is_trivially_copyable (details)
  2. [Tests] Added tests for new instcombine or simplification; NFC (details)
  3. [InstSimplify] Add (~A & B) | ~(A | B) --> ~A (details)
  4. [RISCV] Correct alignment settings for vector registers. (details)
Commit 25c1578a46ff93f920b7ad4e3057465902ced8f5 by alexandre.ganea
Fix llvm::Optional build breaks in MSVC using std::is_trivially_copyable

Current code breaks this version of MSVC due to a mismatch between `std::is_trivially_copyable` and `llvm::is_trivially_copyable` for `std::pair` instantiations.  Hence I was attempting to use `std::is_trivially_copyable` to set `llvm::is_trivially_copyable<T>::value`.

I spent some time root causing an `llvm::Optional` build error on MSVC 16.8.3 related to the change described above:

```
62>C:\src\ocg_llvm\llvm-project\llvm\include\llvm/ADT/BreadthFirstIterator.h(96,12): error C2280: 'llvm::Optional<std::pair<std::pair<unsigned int,llvm::Graph<4>::NodeSubset> *,llvm::Optional<llvm::Graph<4>::ChildIterator>>> &llvm::Optional<std::pair<std::pair<unsigned int,llvm::Graph<4>::NodeSubset> *,llvm::Optional<llvm::Graph<4>::ChildIterator>>>::operator =(const llvm::Optional<std::pair<std::pair<unsigned int,llvm::Graph<4>::NodeSubset> *,llvm::Optional<llvm::Graph<4>::ChildIterator>>> &)': attempting to reference a deleted function (compiling source file C:\src\ocg_llvm\llvm-project\llvm\unittests\ADT\BreadthFirstIteratorTest.cpp)
...
```
The "trivial" specialization of `optional_detail::OptionalStorage` assumes that the value type is trivially copy constructible and trivially copy assignable. The specialization is invoked based on a check of `is_trivially_copyable` alone, which does not imply both `is_trivially_copy_assignable` and `is_trivially_copy_constructible` are true.

[[ https://en.cppreference.com/w/cpp/named_req/TriviallyCopyable | According to the spec ]], a deleted assignment operator does not make `is_trivially_copyable` false. So I think all these properties need to be checked explicitly in order to specialize `OptionalStorage` to the "trivial" version:
```
/// Storage for any type.
template <typename T, bool = std::is_trivially_copy_constructible<T>::value
                          && std::is_trivially_copy_assignable<T>::value>
class OptionalStorage {
```
Above fixed my build break in MSVC, but I think we need to explicitly check `is_trivially_copy_constructible` too since it might be possible the copy constructor is deleted.  Also would be ideal to move over to `std::is_trivially_copyable` instead of the `llvm` namespace verson.

Reviewed By: dblaikie

Differential Revision: https://reviews.llvm.org/D93510
The file was modifiedllvm/include/llvm/ADT/Optional.h
The file was modifiedllvm/unittests/ADT/OptionalTest.cpp
Commit 9fc814ed59669d8f1d06cde5714c17fac652f2a1 by Dávid Bolvanský
[Tests] Added tests for new instcombine or simplification; NFC
The file was modifiedllvm/test/Transforms/InstCombine/or.ll
Commit a4e2a5145a29af678139f33e94ab3df0fc973e59 by Dávid Bolvanský
[InstSimplify] Add (~A & B) | ~(A | B) --> ~A
The file was modifiedllvm/test/Transforms/InstSimplify/or.ll
The file was modifiedllvm/lib/Analysis/InstructionSimplify.cpp
Commit 098dbf190a5586d02f48b84eb41b93b701cdeb97 by kai.wang
[RISCV] Correct alignment settings for vector registers.

According to "9. Vector Memory Alignment Constraints" in V
specification, the alignment of vector memory access is aligned to the
size of the element. In our current implementation, we support ELEN up
to 64. We could assume the alignment of vector registers is 64 under the
assumption.

Differential Revision: https://reviews.llvm.org/D94751
The file was modifiedllvm/lib/Target/RISCV/RISCVRegisterInfo.td