SuccessChanges

Summary

  1. [SROA] Remove Dead Instructions while creating speculative instructions (details)
  2. [RegisterScavenging] Fix assert in scavengeRegisterBackwards (details)
  3. [MCA, ExecutionEngine, Object] Use llvm::is_contained (NFC) (details)
Commit 06d5b1c9ad52476e845f969cf82e00e383f9cf40 by congzhecao
[SROA] Remove Dead Instructions while creating speculative instructions

The SROA pass tries to be lazy for removing dead instructions that are collected during iterative run of the pass in the DeadInsts list.  However it does not remove instructions from the dead list while running eraseFromParent() on those instructions.

This causes (rare) null pointer dereferences.  For example, in the speculatePHINodeLoads() instruction, in the following code snippet:

```
   while (!PN.use_empty()) {
     LoadInst *LI = cast<LoadInst>(PN.user_back());
     LI->replaceAllUsesWith(NewPN);
     LI->eraseFromParent();
   }
```

If the Load instruction LI belongs to the DeadInsts list, it should be removed when eraseFromParent() is called.  However, the bug does not show up in most cases, because immediately in the same function, a new LoadInst is created in the following line:

```
LoadInst *Load = PredBuilder.CreateAlignedLoad(
         LoadTy, InVal, Alignment,
         (PN.getName() + ".sroa.speculate.load." + Pred->getName()));
```

This new LoadInst object takes the same memory address of the just deleted LI using eraseFromParent(), therefore the bug does not materialize.  In very rare cases, the addresses differ and therefore, a dangling pointer is created, causing a crash.

Reviewed By: lebedev.ri

Differential Revision: https://reviews.llvm.org/D92431
The file was modifiedllvm/include/llvm/Transforms/Scalar/SROA.h
The file was modifiedllvm/lib/Transforms/Scalar/SROA.cpp
Commit 698ae90f306248aafbfb5c85cdd9bb81c387bb59 by simon.cook
[RegisterScavenging] Fix assert in scavengeRegisterBackwards

According to the documentation, if a spill is required to make a
register available and AllowSpill is false, then NoRegister should be
returned, however, this scenario was actually triggering an assertion
failure.

This patch moves the assertion after the handling of AllowSpill.

Authored by: Lewis Revill

Reviewed By: arsenm

Differential Revision: https://reviews.llvm.org/D92104
The file was modifiedllvm/lib/CodeGen/RegisterScavenging.cpp
Commit ce94e7d867abf5c08f5b0008f2d31b3f169b815d by kazu
[MCA, ExecutionEngine, Object] Use llvm::is_contained (NFC)
The file was modifiedllvm/lib/Object/MachOObjectFile.cpp
The file was modifiedllvm/lib/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.cpp
The file was modifiedllvm/include/llvm/MCA/HardwareUnits/Scheduler.h