-
Notifications
You must be signed in to change notification settings - Fork 221
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a new flag "--no-entry" #2585
base: main
Are you sure you want to change the base?
Add a new flag "--no-entry" #2585
Conversation
…ion. This is a workaround for some OpenCL drivers that are incompatible with entry points, leading them to have twice the number of kernel arguments. See KhronosGroup#1486 for more details.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Understandable, I'm fine with the option. Please create a test for it.
@@ -278,6 +278,10 @@ static cl::opt<SPIRV::BuiltinFormat> SPIRVBuiltinFormat( | |||
clEnumValN(SPIRV::BuiltinFormat::Global, "global", | |||
"Use globals to represent SPIR-V builtin variables"))); | |||
|
|||
static cl::opt<bool> | |||
NoEntry("no-entry", cl::init(false), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For consistency with other llvm-spirv options:
NoEntry("no-entry", cl::init(false), | |
NoEntry("spirv-no-entry", cl::init(false), |
BM->addEntryPoint(ExecutionModelKernel, BF->getId(), BF->getName(), | ||
auto Name = | ||
BM->getGenerateKernelEntryPoints() ? BF->getName() : I->getName().str(); | ||
BM->addEntryPoint(ExecutionModelKernel, BF->getId(), Name, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this change necessary? If !getGenerateKernelEntryPoints, then BF->getName()==I->getName().str() since BF->getName() will be set by line 885.
Add a new flag "--no-entry" which disables kernel entry point generation. This is a workaround for some OpenCL drivers that are incompatible with entry points, leading them to have twice the number of kernel arguments. See #1486 for more details.
Adding this option allows a single toolchain to be used when compiling kernels for all devices. Some real world instances of this problem:
https://community.intel.com/t5/GPU-Compute-Software/OpenCL-CL-INVALID-KERNEL-ARGS-with-driver-gt-30-0-101-1340/td-p/1420021
https://community.intel.com/t5/GPU-Compute-Software/OpenCL-Kernel-Name-appends-quot-1-quot/m-p/1419720#M644
The workaround is to use ocloc but that adds another toolchain to dev environments and it doesn't have CLC++ support in master just yet.
This might be useful to backport all the way to version 14. I'll open those PRs if this gets approved instead of spamming everything upfront.