[all-commits] [llvm/llvm-project] 5ebbab: [InstCombine] Revert aafde063aaf09285c701c80cd4b54...

[topperc via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 5ebbabc1af360756f402203ba7704bb480f279a7
      https://github.com/llvm/llvm-project/commit/5ebbabc1af360756f402203ba7704bb480f279a7
  Author: Craig Topper <craig.topper at intel.com>
  Date:   2019-12-03 (Tue, 03 Dec 2019)

  Changed paths:
    M llvm/lib/Transforms/InstCombine/InstCombineCasts.cpp
    M llvm/lib/Transforms/InstCombine/InstCombineVectorOps.cpp
    M llvm/test/Transforms/InstCombine/bitcast-vec-canon.ll

  Log Message:
  -----------
  [InstCombine] Revert aafde063aaf09285c701c80cd4b543c2beb523e8 and 6749dc3446671df05235d0a218c426a314ac33cd related to bitcast handling of x86_mmx

This reverts these two commits
[InstCombine] Turn (extractelement <1 x i64/double> (bitcast (x86_mmx))) into a single bitcast from x86_mmx to i64/double.
[InstCombine] Don't transform bitcasts between x86_mmx and v1i64 into insertelement/extractelement

We're seeing at least one internal test failure related to a
bitcast that was previously before an inline assembly block
containing emms being placed after it. This leads to the mmx
state ending up not empty after the emms. IR has no way to
make any specific guarantees about this. Reverting these patches
to get back to previous behavior which at least worked for this
test.