[PATCH] D138899: [DAGCombiner] handle more store value forwarding

[ChenZheng via Phabricator via llvm-commits]

shchenz added a comment.

To me, this patch is innocent for the failure https://bugs.chromium.org/p/chromium/issues/detail?id=1412740. The patch exposes an issue in the pre-ra machine scheduler on X86 target.

Before the  machine scheduler:

  176B      %12:gr32 = LEA32r %fixed-stack.0, 1, $noreg, 0, $noreg
  192B      %6:gr32 = MOV32rm %12:gr32, 1, $noreg, 0, $noreg :: (dereferenceable load (s32) from %ir.4, align 16)     // the content will be stored to 16($esp) is loaded before the filing 0 MOVUPSmr
  208B      MOVUPSmr %18:gr32, 1, $noreg, 0, $noreg, %3:vr128 :: (store (s128) into %ir.1, align 4)
  320B      MOV32mr $esp, 1, $noreg, 16, $noreg, %6:gr32 :: (store (s32))

After the machine scheduler:

  264B      %12:gr32 = LEA32r %fixed-stack.0, 1, $noreg, 0, $noreg
  272B      MOVUPSmr %18:gr32, 1, $noreg, 0, $noreg, %3:vr128 :: (store (s128) into %ir.1, align 4)
  280B      %6:gr32 = MOV32rm %12:gr32, 1, $noreg, 0, $noreg :: (dereferenceable load (s32) from %ir.4, align 16)      // now the content is loaded after the filling 0 MOVUPSmr
  320B      MOV32mr $esp, 1, $noreg, 16, $noreg, %6:gr32 :: (store (s32))

Seems like scheduler does not know `%6:gr32 = MOV32rm` and `MOVUPSmr` are aliased.

@aeubanks Thanks for the quick action. Could you please help to verify if llc option `-enable-misched=false` can solve your issue? I am not very familiar with X86 target, do you have any suggestions about how to fix this X86 scheduling issue? Thank you!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138899/new/

https://reviews.llvm.org/D138899