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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
