karolherbst wrote: The general issue is, that we don't really have any "target specific" notion at this point in time. The same libclc SPIR-V needs to work regardless of the underlying hardware.
The same SPIR-V for instances where fp32 denrom flushing is enabled/disabled/don't care. Same for other aspects like whether there is hardware fma or not. So either we get a combinatorial explosion to cover all those combinations or get a single binary. A mesa target just doesn't really make much sense, because it wouldn't be different than a generic OpenCL target. I'm not against being able to say "let's compile against spirv64-unknown-unknown" I'm against having any user facing way to compile against anything mesa specific, because it's subjected to change and it's not something we want to deal with anyway. And we'd rather have a documented way to tweak the behavior of the single SPIR-V libclc binary than compiling against any assumptions. E.g. denorm flushing behavior could be modeled with spec constants and the code does behave differently depending on whether that constant is set to true or false. But we can't have any of those decisions baked into at compile time. Exactly like any application that would compile OpenCL C to SPIR-V. And we probably want a way to do that from OpenCL C as well (probably should figure out a language extension for this?). So we just don't want any mesa specific triple, because we really just want this to be treated as "application wants to compile OpenCL C" and any target specific information we want to deal with in our runtime, not at compile time. https://github.com/llvm/llvm-project/pull/199618 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
