[llvm-dev] LLVM Backend Legalize Phase

[Craig Topper via llvm-dev]

setOperationAction(Expand) won't split any operations into smaller types.
It just rewrites some operations in terms of other operations on the same
type. And a lot of operations aren't supported as you've noticed as there
is no realistic way to do them using other operations on the same type

~Craig


On Thu, Feb 6, 2020 at 11:26 PM Miguel Inigo J. Manalac via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hello Sebastien,
>
>
>
> Thank you very much for the clarification. This would greatly help us in
> our development.
>
>
>
> I have noticed that setOperationAction(Expand) does not always work, for
> these cases, does it automatically mean that setOperationAction(Custom)
> should be used or not necessarily?
>
> Currently, we perform a pseudo instruction instead of setting it to
> custom.
>
>
>
> For example in the case of a load/store, 8 bits and 16 bits load/store can
> be natively performed but for the 32 bits, we have to expand it into two 16
> bits operations in a pseudo instruction. We have not yet implemented 64
> bits load/store, should we continue using pseudo instruction for this
> considering that instead of expanding we need to load effective address
> from memory and perform load/store 64 bits register with the loaded
> effective address?
>
>
>
> Again, thank you for your help!
>
>
>
> Best,
>
> Miguel
>
>
>
> *From:* Sebastien Le Duc [mailto:sleduc at kalray.eu]
> *Sent:* February 06, 2020 4:27 PM
> *To:* Miguel Inigo J. Manalac
> *Subject:* RE: [llvm-dev] LLVM Backend Legalize Phase
>
>
>
> 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.
> 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.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200206/66b9b39f/attachment.html>