[llvm-dev] [RFC][VECLIB] how should we legalize VECLIB calls?

[Francesco Petrogalli via llvm-dev]

>
>> or we could use SLEEF and support Intel and Arm by using the libmvec compatible version of the library, libsleefgnuabi.so - this is my favorite solution as it is based on the vector function ABI standards of Intel and Arm.
>
> Agreed.
>

With libsleefgnuabi.so it would be indeed easy to bring up the infrastructure needed to cover Arm, Intel and Power, on a variety of OSs (windows, linux, OS X). That could be used for a starting point for tuning the functionality.

>
> 2. Skipping direct codegen
>
> This is a minor issue, but depending on how early this transformation
> passes, it may hinder specialised codegen, particular to the
> architecture, that could have been more efficient.
>
> I don't have any example to hand, but imagine a machine has a sincos
> implementation in scalar that is faster than 2-lane library call. The
> compiler will assume, unwittingly, that the library call is better.
>

There is no way for the compiler to solve this problem without accessing the code of the function, scalar or vector.

The only to possible solutions I see are:

1. Provide runtime libraries as bitcode libraries - then, the bitcode of the call would be visible to the compiler. (SLEEF has already been compiled successfully into a bitcode library and used in a couple of compiler projects).
2. LTO. If the vectorizer generates vector calls that follow Vector Function ABI naming and conventions, a smart linker would be able to associate a scalar function to the vector one, and decide whether to replace such vector call with a loop that uses the faster scalar function.

Francesco


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.