Add Table Gen support to refactor of collectSYCLAttributes()
- Dominant language
- LLVM
- Stars
- 1.5k
- Forks
- 854
- Avg merge
- 3d 17h
- Merged PRs (30d)
- 137
Description
I am starting to think more and more that it's past time to table generate this logic rather than continuing to struggle to maintain these lists manually. Do I understand correctly that we really have one collection need with three (maybe four) modes: never propagate, always propagate, only propagate when directly called (possibly with a diagnostic), but the mode may differ based on the language options? If so, we could perhaps try to design a tablegen feature to do this. e.g., something along the lines of
```
let SYCLKernelPropagationBehavior = [SYCLKernelPropMode, // SYCL 2020 behavior
SYCLKernelPropMode] // SYCL 2017 behavior
```
(Where `SYCL2020` and `SYCL2017` are new `LangOpt` definitions we add to Attr.td and the `*Propagate` are enumerations we define.)
Thinking out loud: we'd generate a function named `static bool isAttributeCollected(const Attr *A, const LanguageOptions &LangOpts, bool IsDirectlyCalled);` that returns whether an attribute should be collected or not. We'd have to collect all of the `SYCLKernelPropagationBehavior` objects in Attr.td so that we could group the language mode checks together in the resulting generated file. What we'd generate would effectively look like:
```
if (LangOpts.getSYCLVersion() == SYCL_2017) {
if (isa(A) && IsDirectlyCalled) // SYCL 2017, propagate if directly called
return true;
if (isa(A)) // SYCL 2017, always propagate
return true;
}
if (LangOpts.getSYCLVersion() >= SYCL_2020) {
if (isa(A) && IsDirectlyCalled) // SYCL 2020, propagate if directly called
return true;
if (isa(A)) // SYCL 2020, always propagate
return true;
}
return false;
```
where each of the generated lists of attributes in the `isa<>` checks are based off the propagation enumeration from Attr.td.
If we want to include diagnostics in the logic, I think we'd return an enumeration rather than a boolean and let the caller figure out what diagnostic to emit, whether to drop the attribute, etc. But given that we only have one of those, we may just want to handle that case specially.
Then, `collectSYCLAttributes()` will defer most of the logic to the generated `isAttributeCollected()`, but can still house any custom logic we need (like for diagnostics).
WDYT? (Note, there may be tweaks needed to the idea -- this was designed somewhat off-the-cuff, so if you have a better idea of how to express this in Attr.td, we should definitely explore it.)
_Originally posted by @AaronBallman in https://github.com/intel/llvm/pull/3836#discussion_r644121865_
Contributor guide
Assessment
This issue has not been assessed yet.