[PATCH] D75298: [Clang][SVE] Parse builtin type string for scalable vectors

Sander de Smalen via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Mar 3 09:40:12 PST 2020


sdesmalen added a comment.

In D75298#1901578 <https://reviews.llvm.org/D75298#1901578>, @efriedma wrote:

> How are you planning to handle them with your current approach?


Each prototype will get a `arm_sve_alias` attribute that specifies which builtin it relates to. For example:

  __attribute__((__clang_arm_sve_alias(__builtin_sve_svld1_u8)))
  svuint8_t svld1(svbool_t, uint8_t const *);
  
  __attribute__((__clang_arm_sve_alias(__builtin_sve_svld1_u32)))
  svuint32_t svld1(svbool_t, uint32_t const *);

This is similar to how this was done for MVE.

> Anyway, that isn't really relevant to the question of why we need to `#define svld1_u8(...) __builtin_sve_svld1_u8(__VA_ARGS__)`, as opposed to just making svld1_u8 an intrinsic.

This is because many of the builtins are protected by an architecture guard like `#ifdef __ARM_FEATURE_SVE` or `#ifdef __ARM_FEATURE_SVE2`.

>> I wouldn't know of a way to create overloaded intrinsics without having to manually do the usual arithmetic conversions similar to how this is currently done for some overloaded builtins like SemaBuiltinAtomicOverloaded in SemaChecking.cpp.
> 
> The current Builtins.def infrastructure isn't really designed around it, but it would be possible to add overloaded intrinsics.  Currently, when a builtin name is looked up, we create one FunctionDecl.  But we could change it to make/return a list of FunctionDecls, instead, and pass them to standard overload resolution.

Do you happen to know which method in Sema does this? I had a look before, but couldn't find where we could do something like this.

> Sort of?  I mean, yes, loading a precompiled module is somewhat cheaper than parsing C.  But it still isn't free, it doesn't really change the fact that the indirection isn't doing anything useful, and we're still making preprocessing/diagnostics more complicated by using defines.

The reason for using `#define`s for the non-overloaded intrinsics was mainly performance, the preprocessor was much faster than having to parse all declarations, with the only downside being the redirection in the diagnostics.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75298/new/

https://reviews.llvm.org/D75298





More information about the cfe-commits mailing list