[llvm-bugs] [Bug 28970] New: Inline ASM IR Considered Harmful

[via llvm-bugs]

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: unassignedbugs at nondot.org
          Reporter: mehdi.amini at apple.com
                CC: llvm-bugs at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160813/a8eb1043/attachment.html>