llvm dev - Feb 2020 - LLVM Backend Legalize Phase

Hello llvm-dev,



Our team is currently creating an LLVM backend for embedded systems. We're
seeking for an advice on the best/correct way to implement our register classes
in the Legalize Phase. As an overview, our backend has 8-bit, 16-bit, 32-bit,
and 64-bit register classes. Our instruction set consist mostly of 8-bit and
16-bit instructions. The 32-bit and 64-bit instructions are commonly used in
memory access operations.

The LLVM Backend reference we used is the AVR. In their implementation, 8-bit
and 16-bit register classes were added with the addRegisterClass function (They
only have up to 16-bit registers) in their TargetLowering. With this, 32-bit and
64-bit operations are automatically split into its equivalent 8/16-bit
operations in the DAG after the Legalize Phase.

For the LLVM Backend we are currently developing, in one hand, adding the 32-bit
and 64-bit register classes would output DAG nodes containing 32/64-bit
operations. This would require us to create pseudo instructions in the TableGen
for expansion to its 8/16-bit equivalent operations. On the other hand, not
adding these register classes would have the same behavior with the AVR.

We are unaware of the consequences of both cases. We have only tested this with
load and store operations for now. We have not verified if the DAG output are
also correct for other operations. What should we consider in deciding what to
use in our implementation?

Thank you very much in advance for your efforts and help!

Best,

Igie

JAPANESE:
このメールは、宛先に書かれている方のみに送信することを意図しております。誤ってそれ以外の方に送信された場合は、申し訳ございませんが、送信者までお知らせいただき、受信されたメールを削除していただきますようお願いいたします。また、コンピュータ・ウィルスの混入等によってメールの欠落・不整合・遅滞等が発生し、何らのご不便をおかけすることが生じても弊社はその責任を負いません。
ENGLISH: This e-mail is intended for the person(s) to which it is addressed. If
you have received it by mistake, please notify the sender and delete the
received email. In addition, our company shall not assume any responsibility
even if it causes any inconvenience, such as loss of mail, inconsistencies,
delays, etc., due to the inclusion of computer viruses.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200206/00b10744/attachment.html>

I think you can make the 32bit and 64bit types legal (using 
addRegisterClass) and use setOperationAction(Expand) for all the operations 
for which you don’t have native support.





From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Miguel 
Inigo J. Manalac via llvm-dev
Sent: Thursday, February 6, 2020 2:27 AM
To: llvm-dev at lists.llvm.org
Subject: [llvm-dev] LLVM Backend Legalize Phase



Hello llvm-dev,



Our team is currently creating an LLVM backend for embedded systems. We're 
seeking for an advice on the best/correct way to implement our register 
classes in the Legalize Phase. As an overview, our backend has 8-bit, 
16-bit, 32-bit, and 64-bit register classes. Our instruction set consist 
mostly of 8-bit and 16-bit instructions. The 32-bit and 64-bit instructions 
are commonly used in memory access operations.

The LLVM Backend reference we used is the AVR. In their implementation, 
8-bit and 16-bit register classes were added with the addRegisterClass 
function (They only have up to 16-bit registers) in their TargetLowering. 
With this, 32-bit and 64-bit operations are automatically split into its 
equivalent 8/16-bit operations in the DAG after the Legalize Phase.

For the LLVM Backend we are currently developing, in one hand, adding the 
32-bit and 64-bit register classes would output DAG nodes containing 
32/64-bit operations. This would require us to create pseudo instructions in 
the TableGen for expansion to its 8/16-bit equivalent operations. On the 
other hand, not adding these register classes would have the same behavior 
with the AVR.

We are unaware of the consequences of both cases. We have only tested this 
with load and store operations for now. We have not verified if the DAG 
output are also correct for other operations. What should we consider in 
deciding what to use in our implementation?

Thank you very much in advance for your efforts and help!

Best,

Igie

JAPANESE: 
このメールは、宛先に書かれている方のみに送信することを意図しております。誤ってそれ以外の方に送信された場合は、申し訳ございませんが、送信者までお知らせいただき、受信されたメールを削除していただきますようお願いいたします。また、コンピュータ・ウィルスの混入等によってメールの欠落・不整合・遅滞等が発生し、何らのご不便をおかけすることが生じても弊社はその責任を負いません。
ENGLISH: This e-mail is intended for the person(s) to which it is addressed. 
If you have received it by mistake, please notify the sender and delete the 
received email. In addition, our company shall not assume any responsibility 
even if it causes any inconvenience, such as loss of mail, inconsistencies, 
delays, etc., due to the inclusion of computer viruses.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200206/19c00eaa/attachment.html>