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

[Francesco Petrogalli via llvm-dev]

> On Oct 10, 2018, at 11:52 AM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> Reading back on the whole thread, I agree with Hideki that we're
> converging into a common solution.
>
> On Wed, 4 Jul 2018 at 17:59, Hal Finkel via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>>> The simplest way to fix it, is to simply only populate the SVML vector library table with __svml_sin_8 when the target is AVX-512.
>>
>> I believe that this is exactly what we should do. When not targeting AVX-512, __svml_sin_8 essentially doesn't exist (i.e. there's no usable ABI via which we can call it), and so it should not appear in the vectorizer's list of options at all.
>
> I agree, too. We already do that with RTLIB calls. A good example is
> DIVREM, which has wildly different legal patterns on common arches.
> AEABI doesn't have REM, so we emit DIVREM, discard the DIV and move
> the REM to the output register.
>
> Having a table of VECLIB calls for various implementations, however,
> is a little harder than GNU vs AEABI. The latter has standard
> documents, the former can change any time, especially if they're not
> maintained by vendors or GNU.
>
> Hideki's proposal to have a "config file" in the implementation (a
> header file with some mappings/attributes would be enough, I think)
> can work for all non-standardised implementations, as well as
> proprietary ones.
>

I am not sure I understand this. Are you saying that the signature of __svml_sin_8 might not conform to the signature that the intel vector function ABI mandates for a 8 lanes version of sin operating on double?
Or is it just a difference in names that raises concerns for SVML? If the latter, I believe that the problem is easily solvable with OpenMP5.0. If the former, it gets indeed more complicated.

> The other new thing would be to look for functions with VF/2... /4...
> /8 until one is found, and add the costs of addition function calls to
> the BB if not equals VF. That should work as long as all types are
> valid, but may back-fire if we add too many shuffles with zero cost.
>
> But that seems trivial compared to maintaining VECLIB.
>
> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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.