[PATCH] D12596: Fix for bootstrap bug introduced in r244921

[hfinkel@anl.gov via llvm-commits]

hfinkel added a comment.

In http://reviews.llvm.org/D12596#268816, @wschmidt wrote:

> In http://reviews.llvm.org/D12596#268715, @nemanjai wrote:
>
> > So the crux of the problem is that the load being replaced has a user of its chain (in this case, a store that nullifies the unique_ptr in the source). Because we introduced the LXVDSX, the use of the chain in the store was not updated and it still used the chain from the load (which goes away). The store was then free to move up (before the LXVDSX) and we end up with a load and splat of a null. I do not see a way to chain the store to this target specific node.
>
>
> So, you're going to have to ensure that the DAG nodes for LXVDSX have chains on them.  This is an oversight in the way things are implemented today.  See what's done for LXVD2X:
>
>   def PPClxvd2x  : SDNode<"PPCISD::LXVD2X", SDT_PPClxvd2x,
>                           [SDNPHasChain, SDNPMayLoad]>;
>   
>
> So you'll need to add LXVDSX to the PPCISD enumeration in PPCISelLowering.h, add an entry like the above in PPCInstrVSX.td, and make sure we expand to that node type in the DAGtoDAG code.  Then you'll have a chain that you can manipulate.


You don't need to add special ISD nodes to do instruction selection in DAGToDAG (only in ISelLowering). LXVDSX is already tagged as mayLoad, and so is already assumed to carry a chain operand. In DAGToDAG we directly generate machine-instruction SDAG nodes. You just need to make sure that chain users are appropriately updated before returning.


Repository:
  rL LLVM

http://reviews.llvm.org/D12596