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

[Renato Golin via llvm-dev]

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.

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