yxsamliu wrote: > This seems like we're _really_ stretching the new interface to match the old > one. The goal is to support users manually modifying `.S` files and then > passing it back into the compiler? I can see how that would be more difficult > with the new interface. I'm not a huge fan of this, the expected behavior was > that you get a `.S` that behaves like a valid host object. > > I would greatly prefer a new, common interface that gave people the same > flexibility rather than bolting more HIP specific handling onto this. But for > the sake of expedience I could be talked into this. > > Theoretically you could make it embed textual assembly in the section, but > you'd need to put that in the filename when you send it back to `clang` > through the linker wrapper. It would also look weird having a bunch of > textual assembly in a global string in an assembly file.
The point of emitting .s file and then compile it to executable is to let users quickly inspect and tweak them. In that sense I think this is a useful feature that I think the new offload driver may consider to keep. Making .s file a binary format will defeat its purpose. However I do agree that we need better fit the feature into the structure of the new offload driver and I think we could refactor that later. https://github.com/llvm/llvm-project/pull/188262 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
