[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 08:07:29 PDT 2017


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


More information about the llvm-dev mailing list