To enable a new implicit kernel argument, increasing the number of argument bytes from 48 to 56.
- rC365643: [AMDGPU] Increased the number of implicit argument bytes for both OpenCL and…
rG18ba9d60771c: [AMDGPU] Increased the number of implicit argument bytes for both OpenCL and…
rL365643: [AMDGPU] Increased the number of implicit argument bytes for both OpenCL and…
can you try compile an empty HIP kernel and see what metadata is generated by backend?
If I remember correctly, backend generates kernel arg metadata based on the number of implicit kernel args. It knows how to handle 48 but I am not sure what will happen if it becomes 56.
The compiler generates metadata for the first 48 bytes. I compiled a sample code and verified it. The backend does nothing for the extra bytes now.
I will soon submit the backend patch to generate the new metadata.
Something that adds ability to handle extra args should be in place at the same time or earlier than the knob that enables the feature.
Ordering of patches matters. You don't know at which revision users will check out the tree and we do want the tree to be buildable and functional at every revision.
Even if breaking the logical order appears to be benign in this case, it would still be better to commit them in order.
I propose to wait until your upcoming patch is up for review, add it as a dependency here and land patches in the right order.