[llvm-dev] RTLIB and Custom Library calls

Mon Mar 2 14:53:07 PST 2020

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>