AlexVlx wrote: > Alex, can you talk about why your design decides to check for specific > builtins rather than building out the set of features supported by > `__builtin_cpu_supports`?
I went into it a bit above without having seen your question (race condition I guess:) ), but to have it in one spot: - AMDGPU features are a bit volatile and subject to disruptive change, sadly (we should be better about this but it's going to be a marathon, and it's not entirely under our - LLVM compiler team - control); - We don't really document the features / they are formulated in a way that makes sense for the BE, and maybe for a compiler dev, but would be extremely confusing for an user - for example note that we have about a dozen `DOT` related features, which aren't always inclusive of each other, so you cannot actually infer that `DOTn` implies `DOTn-1`; - Conversely, the builtins devs reach for most often implement some specific capability i.e. just mirror an ISA instruction that they want to use (e.g. `mfma` / `wmma`), and these are documented via the ISA docs we publish, so having a per-builtin check seemed to match common usage and benefited from what is already in place as opposed to depending on hypothetical long-pole changes. Now, this is specific to AMDGPU, I don't want to speculate too much about how other targets deal with this - which is another reason for which these are target builtins rather than going for something more generic. 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
