[llvm-dev] How to lower a 'Store' node using the list<dag> pattern.

Dominique Torette via llvm-dev llvm-dev at lists.llvm.org
Mon Jul 24 03:34:16 PDT 2017

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),
                                                [(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.


Dominique Torette
System Architect
Rue des Chasseurs Ardennais - Li├Ęge Science Park - B-4031 Angleur
Tel: +32 (0) 4 361 81 11 - Fax: +32 (0) 4 361 81 20



The present message may contain confidential and/or legally privileged information. If you are not the intended addressee and in case of a transmission error, please notify the sender immediately and destroy this E-mail. Disclosure, reproduction or distribution of this document and its possible attachments is strictly forbidden.

SPACEBEL denies all liability for incomplete, improper, inaccurate, intercepted, (partly) destroyed, lost and/or belated transmission of the current information given that unencrypted electronic transmission cannot currently be guaranteed to be secure or error free.
Upon request or in conformity with formal, contractual agreements, an originally signed hard copy will be sent to you to confirm the information contained in this E-mail.

SPACEBEL denies all liability where E-mail is used for private use.

SPACEBEL cannot be held responsible for possible viruses that might corrupt this message and/or your computer system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170724/e1b69148/attachment.html>

More information about the llvm-dev mailing list