AlexVlx wrote: > I think Eli is suggesting something like the rule for > [@available](https://clang.llvm.org/docs/LanguageExtensions.html#objective-c-available): > > * If a builtin is unconditionally available, you can always use it without > any diagnostics. > * If a builtin is only available on specific subtargets, you can only use it > in a block that's guarded by an `if (some_intrinsic(...))` condition that > will only pass if you're running on one of those subtargets. > > So it's not that adding a check for the builtin will suddenly cause > un-checked calls to it to fail, it's that you have to have such a check to > use it in the first place, which makes sense because it's not always > available on the target. >
This is interesting, and I had / have looked at `@available` (albeit I am far from being a scholar on the topic). It makes logical sense, but I expect users will simply ignore it since it is very restrictive if we go with **you have to have a check to use a builtin**. It's not as if all builtin uses today which are present in user code are guarded by `__has_builtin` or by a check against an architecture macro. I will also note that as far as I can see __builtin_available, which we also provide for C & C++, at most warns <https://gcc.godbolt.org/z/Msrrn4x9v>, with the warning being opt-in. It also does not appear to generate any sort of special IR construct, it's just sugar over a call to a runtime provided interface, AFAICT. Furthermore, unlike for `__builtin_available`, there's no immediately apparent way to provide an useful warning here: - if we're compiling for concrete we already know which builtins are available / what target is present, so whether something is legal or not is fully determined; - conversely, for the abstract case we are targeting a generic target which has all the features, so at most we could be somewhat spammy and say "be sure to wrap this in a `__builtin_amdgcn_is_invocable` call; - this only covers a subset of cases, since there are also e.g. per target resource allocation choices, so now we have to hoist into Clang even more architecture details such as the size of shared memory i.e. we'd have to warn; - this'd probably balloon into a non-trivial amount of checking (think the Sema footprint for `@available` is not exactly petite), we'd still at most get to warn, and would still have to run the IR pass, which is actually in a position to correctly diagnose an error state. If the added warning is considered I can loot at adding that but I think that should be a separate patch / conversation since it'd mess with established builtin behaviour (as mentioned, one can reach for an unguarded builtin today without any additional diagnostics / invitation to touch `__has_builtin`, and there are examples where builtins that the FE believes work are actually not available on a target, see, for example, the math ones). > Note that the `@available` model also includes an attribute for marking your > own functions as conditionally available, in which case (1) the entire body > of the function is considered guarded but (2) you have to guard calls to it. > That might be a necessary enhancement for your feature, too. Unless I am missing something obvious, this brings us dangerously close to re-inventing language subsetting / restrictions, that are already present in single-source(-ish) offload languages. It ends up being `__device__` / `restrict(amp)` / `omp declare target` in slightly different clothes. I don't think that is a desirable effect here. At least for our use case (which is what these are trying to support), we need a mechanism that just works with what is already there, and can be directly used from C / C++, with existing C / C++ codebases i.e. has to work with what our library authors have, using idioms they are familiar with. https://github.com/llvm/llvm-project/pull/134016 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
