thr3ads.net - llvm dev - [llvm-dev] LLVM Backend Legalize Phase [Feb 2020]

If this information is useful, please help other people find it:
Share via:

Miguel Inigo J. Manalac via llvm-dev

2020-Feb-07 07:26 UTC

[llvm-dev] LLVM Backend Legalize Phase

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200207/6f3d7cbf/attachment.html>

Craig Topper via llvm-dev

2020-Feb-07 07:42 UTC

head link

[llvm-dev] LLVM Backend Legalize Phase

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>

Eli Friedman via llvm-dev

2020-Feb-07 19:43 UTC

head link

[llvm-dev] LLVM Backend Legalize Phase

For integer operations in particular, operation legalization (LegalizeDAG) has
limited support, yes.  That isn’t really a fundamental limitation; the
infrastructure is generally okay with rewriting operations to use different
(legal) types.  But in practice, we don’t support marking basic integer
operations like “ADD/AND/OR/XOR” as Expand, and it would be painful to implement
in SelectionDAG and DAGCombine because a bunch of places assume they’re legal. 
So in practice, a target that doesn’t have i32 “ADD” should not mark i32 as a
legal type.

If the only “i32” operation the target has is load/store, I’d recommend modeling
an “i32” load as a load of two i16 values.  You can either build these using
custom lowering in SelectionDAG, or merge adjacent loads after isel.  Existing
targets have instructions like this; for example, ldrd on ARM, ldp on AArch64.

-Eli

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Craig
Topper via llvm-dev
Sent: Thursday, February 6, 2020 11:43 PM
To: Miguel Inigo J. Manalac <miguel.manalac at rldp.com.ph>
Cc: llvm-dev at lists.llvm.org
Subject: [EXT] Re: [llvm-dev] LLVM Backend Legalize Phase

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<mailto: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<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<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<mailto: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<mailto: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/20200207/85e7bc87/attachment-0001.html>

Seemingly Similar Threads

Search for more seemingly similar threads

llvm dev - Feb 2020 - LLVM Backend Legalize Phase

[llvm-dev] LLVM Backend Legalize Phase

[llvm-dev] LLVM Backend Legalize Phase

[llvm-dev] LLVM Backend Legalize Phase

Seemingly Similar Threads