FailedChanges

Summary

  1. [LAA] Relax restrictions on early exits in loop structure (details)
  2. [MBP] Prevent rotating a chain contains entry block (details)
  3. Add initial support for multilibs in Baremetal toolchain. (details)
  4. [NFC] cleanup cg-profile emission on TargetLowerinng (details)
  5. [libc++] Split allocator_traits and pointer_traits out of <memory> (details)
Commit f5fe8493e5acfd70da61993cd370816978b9ef85 by listmail
[LAA] Relax restrictions on early exits in loop structure

his is a preparation patch for supporting multiple exits in the loop vectorizer, by itself it should be mostly NFC. This patch moves the loop structure checks from LAA to their respective consumers (where duplicates don't already exist).  Moving the checks does end up changing some of the optimization warnings and debug output slightly, but nothing that appears to be a regression.

Why do this? Well, after auditing the code, I can't actually find anything in LAA itself which relies on having all instructions within a loop execute an equal number of times. This patch simply makes this explicit so that if one consumer - say LV in the near future (hopefully) - wants to handle a broader class of loops, it can do so.

Differential Revision: https://reviews.llvm.org/D92066
The file was modifiedllvm/lib/Transforms/Scalar/LoopLoadElimination.cpp
The file was modifiedllvm/lib/Analysis/LoopAccessAnalysis.cpp
The file was modifiedllvm/lib/Transforms/Scalar/LoopDistribute.cpp
The file was modifiedllvm/lib/Transforms/Utils/LoopVersioning.cpp
Commit d50d7c37a159802c89454a6c53c0ec2e7949d84a by carrot
[MBP] Prevent rotating a chain contains entry block

The entry block should always be the first BB in a function.
So we should not rotate a chain contains the entry block.

Differential Revision: https://reviews.llvm.org/D92882
The file was modifiedllvm/lib/CodeGen/MachineBlockPlacement.cpp
Commit 670686ad8ecc80158a6ff87fff55e0ffa6fdff5d by abidh
Add initial support for multilibs in Baremetal toolchain.

This patch add support of riscv multilibs in the Baremetal toolchain. It is
a bit different to what is done in GNU.cpp as we are not iterating a
GNU sysroot to find the multilibs. This is intended for an llvm only
toolchain. We are not checking for the presence of any runtime bits to
enable a specific multilib.

I have structured the patch so that other targets for which
there is no multilibs support yet in Baremetal.cpp (e.g. arm-none-eabi)
will not be affected. Patch also allows some multilibs reuse.

Long term, I would like to go in the direction of data-driven specification of
multilib directories and flags.

Reviewed By: jroelofs

Differential Revision: https://reviews.llvm.org/D93138
The file was modifiedclang/lib/Driver/ToolChains/BareMetal.h
The file was modifiedclang/test/Driver/baremetal.cpp
The file was modifiedclang/lib/Driver/ToolChains/BareMetal.cpp
Commit b6b522c4db17157d871eff974e5283058bc616a1 by zequanwu
[NFC] cleanup cg-profile emission on TargetLowerinng

Differential Revision: https://reviews.llvm.org/D93150
The file was modifiedllvm/include/llvm/Target/TargetLoweringObjectFile.h
The file was modifiedllvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp
The file was modifiedllvm/lib/Target/TargetLoweringObjectFile.cpp
The file was modifiedllvm/include/llvm/CodeGen/TargetLoweringObjectFileImpl.h
Commit 7ad49aec125b3c1205b164331d0aa954d773f890 by Louis Dionne
[libc++] Split allocator_traits and pointer_traits out of <memory>

In addition to making the code a lot easier to grasp by localizing many
helper functions to the only file where they are actually needed, this
will allow creating helper functions that depend on allocator_traits
outside of <memory>.

This is done as part of implementing array support in allocate_shared,
which requires non-trivial array initialization algorithms that would be
better to keep out of <memory> for sanity. It's also a first step towards
splitting up our monolithic headers into finer grained ones, which will
make it easier to reuse functionality across the library. For example,
it's just weird that we had to define `addressof` inside <type_traits>
to avoid circular dependencies -- instead it's better to implement those
in true helper headers.

Differential Revision: https://reviews.llvm.org/D93074
The file was addedlibcxx/include/__memory/allocator_traits.h
The file was addedlibcxx/include/__memory/base.h
The file was modifiedlibcxx/include/CMakeLists.txt
The file was modifiedlibcxx/test/std/containers/sequences/vector/vector.cons/copy.move_only.verify.cpp
The file was modifiedlibcxx/include/iterator
The file was modifiedlibcxx/include/type_traits
The file was addedlibcxx/include/__memory/pointer_traits.h
The file was modifiedlibcxx/include/memory
The file was modifiedlibcxx/include/exception
The file was modifiedlibcxx/test/std/containers/sequences/vector/vector.modifiers/resize_not_move_insertable.fail.cpp