[llvm-dev] TableGen customized node with mayStore attribute is deleted if there is no use

[Xiangyang Guo via llvm-dev]

Hi,

I define a customized node with customized type. The job of this customized
node is to move a value from one register class to another class. I find
that if there is no use of the destination register, this node will be
deleted from SDAG. For some reasons, I want to keep this node. So I attach
mayStore attribute to this node and I hope it will not be deleted. However,
it does not work like I assume. There must be something wrong. But I don't
know it's because this trick does not work in theory  or it's because my
implementation is wrong.

def MoveTy : SDTypeProfile<1, 1, []>;
def MoveFlag : SDNode<"FOOISD::MOVE_FLAG", MoveTy, [SDNPHasChain,
SDNPSideEffect, SDNPMayStore, SDNPMayLoad]>;

let hasSideEffects = 1, mayStore = 1, mayLoad = 1 in {
def MOVE : InstFOO<(outs ARegs:$dst), (ins BRegs:$src),
                    "move $dst, $src",
                     [(set i32:$dst, (MoveFlag i32:$src))]>;

For example, I add this node into SDAG when I want to move the formal
argument from the specific register class to other register class. I
implement it in LowerFormalArguments() like this:
  ....
  for (auto &VA : ArgLocs) {
    if (VA.isRegLoc()) {
      // Arguments passed in registers
      EVT RegVT = VA.getLocVT();
      VReg = RegInfo.createVirtualRegister(&FOO::BRegsRegClass);
      RegInfo.addLiveIn(VA.getLocReg(), VReg);
      SDValue ArgIn = DAG.getCopyFromReg(Chain, dl, VReg, RegVT);
      SDValue ArgIn_copy = DAG.getNode(FOOISD::MOVE_FLAG , dl, MVT::i32,
Chain, ArgIn); // this node is added in order to move the value from BRegs
class to ARegs class and I want it be kept even it is not used later on
      InVals.push_back(ArgIn_copy);
    }
  }

After checking the recursivelyDeleteUnusedNodes() in DAGCombinner.cpp, this
function will delete the unused node and it does not care about the other
attributes.

I must have something wrong. I appreciate if you can point it out. Any
suggestion is appreciable.

Regards,

Xiangyang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160131/774a557b/attachment.html>