Allow for potential customization of TLII

[vchuravy]

Currently NFC.
The most interesting option is to disallow all libcalls,
or enable vectorization.

We could investigate:

  /// Return true if the function F has a vector equivalent with any
  /// vectorization factor.
  bool isFunctionVectorizable(StringRef F) const;
 
  /// Return the name of the equivalent of F, vectorized with factor VF. If no
  /// such mapping exists, return the empty string.
  StringRef getVectorizedFunction(StringRef F, const ElementCount &VF,
                                  bool Masked) const;

[gbaraldi]

Would this allow us to give back something like a vectorized sin?

[vtjnash]

This seems a little risky, since LLVM declares that compilation can be done repeatably (in llc or opt for example) with this derived only from the triple:

This class [TargetLibraryInfoImpl] constructs tables that hold the target library information and make it available. However, it is somewhat expensive to compute and only depends on the triple. So users typically interact with the TargetLibraryInfo wrapper below.

Could we propose some sort of Metadata feature for LLVM that would replace the current magic global behavior of the TLII with explicit data found in the Module IR?

[vchuravy]

Would this allow us to give back something like a vectorized sin?

Yes in theory, but we probably need a better mechanism than string matching.

This seems a little risky

This is what Clang does xD

[gbaraldi]

Vectorized safepoints?

[vchuravy]

On issue with interoducing GC.safepoint() in a loop is that it blocks loop vectorization. This still doesn't fix it, but I need to look into wat the vectorize yes for decision making here