jdoerfert wrote: > There's two things that come to mind for this, OpenCL extensions and kernel > attributes. OpenCL lets you do things like > > ``` > #pragma OPENCL EXTENSION <extension_name> : <behavior> > ``` > > Which are supposed to influence the code generated, which could conceivably > extend to a runtime. Kernel attributes are the canonical way to state that a > kernel doesn't need something. OpenMP doesn't really expose kernels, and the > OpenMP runtime is global state so it's strange. I'm generally against > introducing new clang driver flags for increasingly specific behavior.
You can attach information on a kernel or in a file with ompx or requires (or better assume), agreed. It's cumbersome and not practical for many people, hence flags. The standard even goes that way. That said, I still don't understand how that relates to the globals you mentioned before. I get that if you annotate a kernel (or better all device functions) with some attribute, that's fine, you can read it in the middle end, but you need again some special codegen to make it runtime accessible, no? So we still need a global or a call somewhere, or am I missing something? > > The way these are handled right now is just magic config globals we rely on > LTO to fix-up, I.e. > `OMPBuilder.createGlobalFlag(CGM.getLangOpts().OpenMPNoThreadState)`. Surely > there's a way to inject this behavior without a new driver flag every time? We don't rely on LTO to "fix up" anything. It (should/used to) work fine without LTO. The performance hit you get without LTO is not because of those flags, but because of many other reason. On that note, we could (as others are still doing) version the entire runtime into 4 or more states that are then called due to the magic syntax in the frontend. So you have init_default, init_cond1, init_cond2, init_cond3, etc. but all that does is replicate your bugs in the runtime 4 times, diverge code over time, and, so far in all implementations I've seen, rely on syntax information alone, which limits this to the slide code examples. https://github.com/llvm/llvm-project/pull/178914 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
