- Do not emit following assembler directives:
- Do not emit .note entries
- Cleanup and bring in sync kernel descriptor header file
- Emit kernel descriptor into .rodata with appropriate relocations and alignments
Isn't the REL64 here redundant? The way I see it, we should either have an absolute reference to (start of kernel code) - (start of kernel descriptor), or a relative reference to (start of kernel code) - offsetof(kernel_descriptor_t, kernel_code_entry_byte_offset).
I'm not deep enough in MC to say for certain which of these is really preferable.
The field requires an offset to the entry point so an absolute relocation cannot be used. The Rel64 relocation record is what describes what is needed. Since the kernel descriptor and entry point are now in different sections, a static relocation record is needed so that it can be fixed up when the relocatable code object is linked to make a shared object.
Previously the kernel descriptor was put in the same section as the code, and the offset was "hard-wired" when it was generated.
Suggest just linking to "https://llvm.org/docs/AMDGPUUsage.html#kernel-descriptor" as this may support other targets in the future.
Should this be:
What does "Must be kept backwards compatible." mean? Arn't these just the meaning of the values? Or is the issue that they may change value on different targets in the future?
uint32_t to match `uint32_t compute_pgm_rsrc1;`?
uint32_t to match `uint32_t compute_pgm_rsrc2;`?
Should this be uint16_t since the kernel descriptor field is `uint16_t kernel_code_properties;`?
Right, I agree that a REL64 relocation is ultimately needed. My point is more about how to express that fact inside LLVM using the MCExpr framework.
I read the expressing that is being created here as literally (start of kernel code) - (start of kernel descriptor). The fact that it's a relative relocation really ought to be implied by that already, it's not clear to me why VK_AMDGPU_REL64 is passed to one of the constructors in addition to that.