SuccessChanges

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

Summary

  1. [PowerPC] Fix crash in peephole optimization (details)
  2. [InstCombine] Revert rL341831: relax one-use check in (details)
Commit 241cbf201a6f4b7658697e3c76fc6e741d049a01 by nemanja.i.ibm
[PowerPC] Fix crash in peephole optimization
When converting reg+reg shifts to reg+imm rotates, we neglect to
consider the CodeGenOnly versions of the 32-bit shift mnemonics. This
means we produce a rotate with missing operands which causes a crash.
Committing this fix without review since it is non-controversial that
the list of mnemonics to consider should include the 64-bit aliases for
the exact mnemonics.
Fixes PR44183.
The file was modifiedllvm/lib/Target/PowerPC/PPCInstrInfo.cpp
The file was addedllvm/test/CodeGen/PowerPC/pr44183.ll
Commit 0f22e783a038b6983f0fe161eef6cf2add3a4156 by lebedev.ri
[InstCombine] Revert rL341831: relax one-use check in
foldICmpAddConstant() (PR44100)
rL341831 moved one-use check higher up, restricting a few folds that
produced a single instruction from two instructions to the case where
the inner instruction would go away.
Original commit message:
> InstCombine: move hasOneUse check to the top of foldICmpAddConstant
>
> There were two combines not covered by the check before now,
> neither of which actually differed from normal in the benefit
analysis.
>
> The most recent seems to be because it was just added at the top of
the
> function (naturally). The older is from way back in 2008 (r46687)
> when we just didn't put those checks in so routinely, and has been
> diligently maintained since.
From the commit message alone, there doesn't seem to be a deeper
motivation, deeper problem that was trying to solve, other than 'fixing
the wrong one-use check'.
As i have briefly discusses in IRC with Tim, the original motivation can
no longer be recovered, too much time has passed.
However i believe that the original fold was doing the right thing, we
should be performing such a transformation even if the inner `add` will
not go away - that will still unchain the comparison from `add`, it will
no longer need to wait for `add` to compute.
Doing so doesn't seem to break any particular idioms, as least as far as
i can see.
References https://bugs.llvm.org/show_bug.cgi?id=44100
The file was modifiedllvm/test/Transforms/LoopVectorize/if-conversion-nest.ll
The file was modifiedllvm/test/Transforms/LoopUnroll/runtime-loop-multiple-exits.ll
The file was modifiedllvm/lib/Transforms/InstCombine/InstCombineCompares.cpp
The file was modifiedllvm/test/Transforms/LoopVectorize/runtime-check.ll
The file was modifiedllvm/test/Transforms/InstCombine/icmp-add.ll