llvm dev - Jul 2017 - 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.








[http://www.spacebel.be/wp-content/uploads/2011/06/image-sign-sbp.jpg]

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
www.spacebel.be<http://www.spacebel.be/>



 ------------------------------------------------------------------------------

E-MAIL DISCLAIMER

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>

Hi Dominique,

On 24 July 2017 at 03:34, Dominique Torette via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>             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.

-----Original Message-----
From: Tim Northover [mailto:t.p.northover at gmail.com] 
Sent: lundi 24 juillet 2017 16:06
To: Dominique Torette
Cc: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] How to lower a 'Store' node using the
list<dag> pattern.

Hi Dominique,

On 24 July 2017 at 03:34, Dominique Torette via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>             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.

 ------------------------------------------------------------------------------

E-MAIL DISCLAIMER

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.
 -------------------------------------------------------------------------------