[GC] Loosen ordering on statepoint reloads to allow CSE
authorPhilip Reames <listmail@philipreames.com>
Wed, 11 Mar 2020 18:12:28 +0000 (11:12 -0700)
committerPhilip Reames <listmail@philipreames.com>
Wed, 11 Mar 2020 19:30:06 +0000 (12:30 -0700)
commit8f997b4f0118a8f9cd5c1071b61bfbc35a7e7e85
tree9414c8be9eb7ea18f7b0b6e5dd18e3833274d901
parentf1736f7a2a660944c24aac45e24cdf1ea6c6effa
[GC] Loosen ordering on statepoint reloads to allow CSE

We just removed a broken duplicate elimination algorithm in D75964, and after landed that it occurred to me that duplicate elimination is simply CSE. SelectionDAG has a build in CSE, so why wasn't that triggering? Well, it turns out we were overly conservative in the memory states for our reloads and CSE (rightly) considers the incoming memory state for a load part of the identity of the load.

By loosening the chain and allowing reordering, we also allow CSE. As shown in the test case, doing iterative CSE as we go is enough to eliminate duplicate stores in later statepoints as well. We key our (block local) slot map by SDValue, so commoning a previous pair of loads at construction time means we also common following stores.

Differential Revision: https://reviews.llvm.org/D76013
llvm/lib/CodeGen/SelectionDAG/StatepointLowering.cpp
llvm/test/CodeGen/X86/statepoint-duplicates-export.ll