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)

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.

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

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