How to lower a 'Store' node using the list<dag> pattern.

Hi,

I’m trying to complete the lowering for a new microcontroller. I’m using LLVM 3.8.

For now this lowering crashes on ‘Store’ node, which is actually not yet defined.

I’ve tried to map the ISel ‘Store’ node to architecture specific instructions.

I’ve define the following semantic to my architecture specific instructions:

def MOVSUTO_SU_rr : CLPSUInst_rr<0b1000001100,

(ins SURegisterOperand:$RegA),

(outs SURegisterOperand:$RegB),

[],

“movsuto_su\t$RegA,$RegB”,“RR”,

[(store (i16 SURegisterOperand:$RegA), i16:$RegB)], NoItinerary>

{

bits<9> RegA;

bits<9> RegB;

let Inst{19-11} = RegA;

let Inst{8-0} = RegB;

}

SURegisterOperand are 16 bits operands.

During the generation of ISelection matchers tables, I got the following assertion.

This assertion start to occur when the pattern is introduced on the MOVSUTO_SU_rr.

How to avoid such assertion? What is a concrete type? According to the definition of SURegisterOperand, these are 16 bits signed integer.

Hi Dominique,

            def MOVSUTO_SU_rr : CLPSUInst_rr<0b1000001100,
                                                (ins SURegisterOperand:$RegA),
                                                (outs SURegisterOperand:$RegB),
                                                [],
                                                "movsuto_su\t$RegA,$RegB","RR",
                                                [(store (i16 SURegisterOperand:$RegA), i16:$RegB)], NoItinerary>

Store instructions usually just have two "ins" operands (the value to
be stored and the address to store it). Their actual "out" is actually
memory, which LLVM doesn't model at this level.

This is certainly what LLVM's "store" DAG node is expecting to deal
with and could easily cause an assertion failure in tablegen.

Cheers.

Tim.

Thanks Tim, That's right: both operands should be 'ins'. Just discovered on my own.