jhuber6 wrote: Did a quick scan since I forget how AMD handles this internally. The canonical handling comes from the AMD code object manager, which is a utility in the LLVM fork so it shares the changes you're making here. This should be fine. https://github.com/ROCm/llvm-project/blob/51af0aed650e2f3bf2b8a9af860f643184276508/amd/comgr/src/comgr-unbundle-command.cpp#L146-L147
However, there's a direct byte read in the HIP runtime which won't pick anything up. In practice I believe ROCm only ships on LE architectures so I'm not sure how much we should care, I'm not and authority on the HIP runtime. https://github.com/ROCm/rocm-systems/blob/1b222fa464e705a32f204ba08d308b02f74bdc26/projects/clr/hipamd/src/hip_fatbin.cpp#L221-L222 I'm not really sure what the proper solution is for endianness. Currently the status quo is that these are generated by the compiler when you compile your HIP object, so as long as they share the same data layout everything works. My main concern is that if we tie this to LE we'd need to update all users and it would add byte swapping overhead, but given that we don't ship to BE yet anyway I doubt that's a blocker. https://github.com/llvm/llvm-project/pull/205822 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
