llvm dev - Mar 2020 - RTLIB and Custom Library calls

Hello LLVM-Dev,

Most of the processing for i64 and f64 types for our backend are emulation
library calls. Some of the library calls are not defined in the
RuntimeLibcalls.def Libcall enum so we have to define custom library calls.

How is the ideal way of implementing the custom library calls? Providing us with
a target backend having a similar functionality would also help us
significantly.
Say for a i64 type compare, does adding it in the RuntimeLibcalls.def enum,
SelectionDAGLegalize::ConvertNodeToLibcall function, and the target ISelLowering
Class solve our problem?
Is it okay to modify RuntimeLibcalls.def and
SelectionDAGLegalize::ConvertNodeToLibcall function?
A starting point for processing lib calls other than the ISelLowering class
would also help!

Thank you in advance for your help!

Sincerely,
Miguel Inigo J. Manalac (1852)

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/20200302/333dc4e0/attachment.html>

If you're looking for examples, I think most backends will generate libcalls
(for things they don't support). I don't look at other backends too
much, but perhaps a simple example from the ARM backend is compiling this
example:

double foo(double a, double b) {
  return a < b;
}

for a core that doesn't support natively double precision operations (e.g.
compile with --target=arm-arm--eabihf -mcpu=cortex-m4). If you request debug and
-print-after-all on the command line, you can trace where the different things
get introduced and generated. For this fcmp example in the ARM backend, you will
see that it all kind of starts with describing the SETCC operation, which
generates this fcmp, to "expand" for the f64 data type. This is picked
up by the generic type legalizer, which will query backends to see if it e.g.
needs to "soften" float operands. Also, in the backend you will see
mappings from the generic library calls, to the target specific libcalls. This
is a very briefly description, but I don't think it works much different for
other cases. For the i64 cases, you perhaps don't need libcalls as it can be
done with 32-bit instruction, like in the ARM backed.

There have been quite a number of talks on how writing your own backend on the
llvm dev conferences. Although I haven't checked, I guess they they spent
some slides on this, so perhaps you can get some inspiration from there.

Hope this helps a bit.


________________________________
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Miguel
Inigo J. Manalac via llvm-dev <llvm-dev at lists.llvm.org>
Sent: 02 March 2020 07:33
To: llvm-dev <llvm-dev at lists.llvm.org>
Subject: [llvm-dev] RTLIB and Custom Library calls


Hello LLVM-Dev,



Most of the processing for i64 and f64 types for our backend are emulation
library calls. Some of the library calls are not defined in the
RuntimeLibcalls.def Libcall enum so we have to define custom library calls.



How is the ideal way of implementing the custom library calls? Providing us with
a target backend having a similar functionality would also help us
significantly.

Say for a i64 type compare, does adding it in the RuntimeLibcalls.def enum,
SelectionDAGLegalize::ConvertNodeToLibcall function, and the target ISelLowering
Class solve our problem?

Is it okay to modify RuntimeLibcalls.def and
SelectionDAGLegalize::ConvertNodeToLibcall function?

A starting point for processing lib calls other than the ISelLowering class
would also help!



Thank you in advance for your help!



Sincerely,

Miguel Inigo J. Manalac (1852)



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/20200302/39f66014/attachment.html>

On Mon, Mar 02, 2020 at 11:29:58AM +0000, Sjoerd Meijer via llvm-dev
wrote:
> If you're looking for examples, I think most backends will generate
> libcalls (for things they don't support). I don't look at other
> backends too much, but perhaps a simple example from the ARM backend
> is compiling this example:
MIPS might be a better example in this case, because ARM has custom
names for most of the operations. In general, most i64 operations should
get expanded inline to i32 operations. The only exception really is
division. f64 has software emulation on a lot of embedded platforms,
there should be anything special necessary.

Joerg

Hello Sjoerd,

Although this is a solution that may fix our problem, our target architecture
specifies that operations for types i32, i64, f32, and f64 are supported by
using emulation routines/libraries. Considering this specification, there is a
need to define the i32 and i64 operations (as custom library calls) that are not
defined in the generic library calls.

Thank you for helping!

Best,
Miguel

From: Sjoerd Meijer [mailto:Sjoerd.Meijer at arm.com]
Sent: March 02, 2020 7:30 PM
To: llvm-dev; Miguel Inigo J. Manalac
Subject: Re: RTLIB and Custom Library calls

If you're looking for examples, I think most backends will generate libcalls
(for things they don't support). I don't look at other backends too
much, but perhaps a simple example from the ARM backend is compiling this
example:

double foo(double a, double b) {
  return a < b;
}

for a core that doesn't support natively double precision operations (e.g.
compile with --target=arm-arm--eabihf -mcpu=cortex-m4). If you request debug and
-print-after-all on the command line, you can trace where the different things
get introduced and generated. For this fcmp example in the ARM backend, you will
see that it all kind of starts with describing the SETCC operation, which
generates this fcmp, to "expand" for the f64 data type. This is picked
up by the generic type legalizer, which will query backends to see if it e.g.
needs to "soften" float operands. Also, in the backend you will see
mappings from the generic library calls, to the target specific libcalls. This
is a very briefly description, but I don't think it works much different for
other cases. For the i64 cases, you perhaps don't need libcalls as it can be
done with 32-bit instruction, like in the ARM backed.

There have been quite a number of talks on how writing your own backend on the
llvm dev conferences. Although I haven't checked, I guess they they spent
some slides on this, so perhaps you can get some inspiration from there.

Hope this helps a bit.


________________________________
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Miguel
Inigo J. Manalac via llvm-dev <llvm-dev at lists.llvm.org>
Sent: 02 March 2020 07:33
To: llvm-dev <llvm-dev at lists.llvm.org>
Subject: [llvm-dev] RTLIB and Custom Library calls


Hello LLVM-Dev,



Most of the processing for i64 and f64 types for our backend are emulation
library calls. Some of the library calls are not defined in the
RuntimeLibcalls.def Libcall enum so we have to define custom library calls.



How is the ideal way of implementing the custom library calls? Providing us with
a target backend having a similar functionality would also help us
significantly.

Say for a i64 type compare, does adding it in the RuntimeLibcalls.def enum,
SelectionDAGLegalize::ConvertNodeToLibcall function, and the target ISelLowering
Class solve our problem?

Is it okay to modify RuntimeLibcalls.def and
SelectionDAGLegalize::ConvertNodeToLibcall function?

A starting point for processing lib calls other than the ISelLowering class
would also help!



Thank you in advance for your help!



Sincerely,

Miguel Inigo J. Manalac (1852)


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/20200302/d823ff9c/attachment.html>

Hi LLVM-Dev,

Upon investigation, to implement the custom library calls, we have to do the
following:

-      Add cases for the operations in getRTLibDesc static function
(LegalizerHelper.cpp)

-      Add cases for the operations in
SelectionDAGLegalize::ConvertNodeToLibcall (LegalizeDAG.cpp)

-      Add the enums for the operations in the RuntimeLibcalls.def

-      Add a setLibcallName function call for each operation and implement Lower
operations in the target ISelLowering class

We do not want to modify non-target files/projects as this will have side
effects for other targets. Will this be possible?
If not, are there boolean functions available for checking the
triple/architecture used in the mentioned classes above? Example : isArch(x86)
Does setLibcallName(RTLIB::SDIV_I8, nullptr) set the RTLIB::SDIV_I8 as not
supported?
Is there a guide that exists which could help us in implementing custom library
calls? Or perhaps a target which implemented something like this? I have checked
google and the LLVM youtube channel, not much help.

Thank you very much in advance for all the help!

Best,
Miguel

From: Miguel Inigo J. Manalac
Sent: March 02, 2020 3:34 PM
To: llvm-dev
Subject: RTLIB and Custom Library calls

Hello LLVM-Dev,

Most of the processing for i64 and f64 types for our backend are emulation
library calls. Some of the library calls are not defined in the
RuntimeLibcalls.def Libcall enum so we have to define custom library calls.

How is the ideal way of implementing the custom library calls? Providing us with
a target backend having a similar functionality would also help us
significantly.
Say for a i64 type compare, does adding it in the RuntimeLibcalls.def enum,
SelectionDAGLegalize::ConvertNodeToLibcall function, and the target ISelLowering
Class solve our problem?
Is it okay to modify RuntimeLibcalls.def and
SelectionDAGLegalize::ConvertNodeToLibcall function?
A starting point for processing lib calls other than the ISelLowering class
would also help!

Thank you in advance for your help!

Sincerely,
Miguel Inigo J. Manalac (1852)

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/20200312/37debcbc/attachment-0001.html>