https://llvm.org/bugs/show_bug.cgi?id=28970
Bug ID: 28970 Summary: Inline ASM IR Considered Harmful Product: new-bugs Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: mehdi.am...@apple.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified TL/DR: I propose to change our inline ASM representations (both call to inline asm and module level inline asm) to enrich it with the list of symbol defined and referenced. Our internal representation for inline ASM is an opaque blob till we reach the MC layer. This is harmful for any use of LLVM IR and Bitcode other than a straight compiler pipeline. For example the following does not compile with LTO on Darwin at this time: $ cat inline_asm.c void foo() {} int main() { asm("call _foo" : : ); } $ clang inline_asm.c $ clang inline_asm.c -flto ld: reference to symbol (which has not been assigned an address) _foo in '_main' from /var/folders/4z/k9mg8rls7wsfm6t6hbm0_bxw0000gn/T/cc-032652.o for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) The following does not compile (even without LTO) without forcing an attribute "used" on foo(): static void foo() {} int main() { asm("call _foo" : : ); } The following defines a function bar(): asm(".text\n" ".globl _bar\n" "_bar:\n" "\tret\n" ); And will generate this IR: module asm ".text" module asm ".globl _bar" module asm "_bar:" module asm "\09ret" All tools that handles bitcode files where we usually have objects need to workaround this. Instead of hacking on these opaque string, we should embed in the IR and in the Bitcode the informations that are needed to handle these files on par with regular object files. The fact that tools like `nm` and `ar` have to link all the backends for the only purpose of supporting inline ASM properly seems like a good indication that we're missing a layer. I think enriching Inline ASM IR construct with the list of symbols defined and referenced would solve this issue. The frontend would be responsible to have a target with ASM parser available to build this list from opaque blob. However, this would likely be an issue for targets for which we don't have an integrated assembler. I don't have a good solution for this at that time. -- You are receiving this mail because: You are on the CC list for the bug.
_______________________________________________ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs