1. [PowerPC] Test case for vector float gather on ppc64le and ppc64 (details)
  2. Reland: [Remarks][Driver] Use different remark files when targeting (details)
  3. [LoopPred/WC] Use a dominating widenable condition to remove analyze (details)
Commit 9d93893914086738c577a4f4f1089f6a004a2261 by stefanp
[PowerPC] Test case for vector float gather on ppc64le and ppc64
Test case to verify that the expected code is generated for a vector
float gather based on the patterns in tablegen for big and little endian
Patch by: Kamau Bridgeman
Differential Revision:
The file was addedllvm/test/CodeGen/PowerPC/float-vector-gather.ll
Commit e15b26fbbd901315a1402f97e83abf29bdce9a9f by francisvm
Reland: [Remarks][Driver] Use different remark files when targeting
multiple architectures
When the driver is targeting multiple architectures at once, for things
like Universal Mach-Os, we need to emit different remark files for each
cc1 invocation to avoid overwriting the files from a different
For example:
$ clang -c -o foo.o -fsave-optimization-record -arch x86_64 -arch
will create two remark files:
* foo-x86_64.opt.yaml
* foo-x86_64h.opt.yaml
The file was addedclang/test/Driver/darwin-opt-record.c
The file was modifiedclang/lib/Driver/ToolChains/Clang.cpp
Commit ad5a84c883354e8bb595ebfd9971fe4a14b770fd by listmail
[LoopPred/WC] Use a dominating widenable condition to remove analyze
loop exits
This implements a version of the predicateLoopExits transform from
IndVarSimplify extended to exploit widenable conditions - and thus be
much wider in scope of legality. The code structure ends up being almost
entirely different, so I chose to duplicate this into the
LoopPredication pass instead of trying to reuse the code in the IndVars.
The core notions of the transform are as follows:
    If we have a widenable condition which controls entry into the loop,
we're allowed to widen it arbitrarily. Given that, it's simply a
*profitability* question as to what conditions to fold into the
widenable branch.
   To avoid pass ordering issues, we want to avoid widening cases that
would otherwise be dischargeable. Or... widen in a form which can still
be discharged. Thus, we phrase the transform as selecting one
analyzeable exit from the set of analyzeable exits to keep. This avoids
creating pass ordering complexities.
   Since none of the above proves that we actually exit through our
analyzeable exits - we might exit through something else entirely - we
limit ourselves to cases where a) the latch is analyzeable and b) the
latch is predicted taken, and c) the exit being removed is statically
Differential Revision:
The file was modifiedllvm/lib/Transforms/Scalar/LoopPredication.cpp
The file was addedllvm/test/Transforms/LoopPredication/predicate-exits.ll