[clang] [Clang][HLSL] Add environment parameter to availability attribute (PR #89809)

Chris B via cfe-commits cfe-commits at lists.llvm.org
Mon Apr 29 07:39:40 PDT 2024


llvm-beanz wrote:

> While I like the approach of aligning availability parameters closer to `llvm::Triple`, I am concerned about how this will interact with existing precedent. There is a lot of code that passes in _platform_ values that aren't actually `OSType`. For example `__attribute__((availability(macCatalyst, ...))` aligns to `EnviornmentType::MacABI` and `__attribute__((availability(macOSApplicationExtension, ...)))` aligns to cli args `-mtargetos=macos -fapplication-extension`.

`macCatalyst` would work perfect with the new structure because the platform is `iOS` and the environment is `macabi` (or you could change the string to `catalyst`. App extensions are kinda a weird case because on the one hand, the compiler largely doesn't need to know about them (except for availability), but they drive linking differently.

> It may become difficult to maintain the distinction between what is accepted as a `platform` vs a `environment`. And we can't realistically re-write client code relying on this.

I wouldn't expect rewriting existing code. The new argument added in this PR is optional, so you can use it or not. It seemed like it had the possibility to simplify the use cases. For example, if `app_extension` were an environment you wouldn't need to add multiple new platform cases for each new platform.

For us this is a big deal because we effectively have 16 environments that are basically all supported across 2 platforms (shader model and Vulkan).

> This attribute behavior also aligns very closely with Swift's `@available` Would it be possible to similarly treat the target shader stages & combinations as platform values as well? Or define a new attribute that does not conflict.

It would be preferable for us to separate environment and platform, but that doesn't mean Apple needs to. I think you should consider it because it is a more forward looking and maintainable approach, but I don't think there is any reason why we can't add this argument field while Apple continues to only support the legacy platform strings.



https://github.com/llvm/llvm-project/pull/89809


More information about the cfe-commits mailing list