LTO scan of module-level inline assembly does not respect CPU

[mysterymath]

The scan of module-level inline assembly performed to extract the referenced symbols does not forward the CPU specified on the clang command line. Because of this, opcodes that are only legal in that CPU will cause the compile to fail in -flto where it would have succeeded without. For example:

asm(".globl func; func: cm.mvsa01 s1, s0; ret");

This succeeds when compiled for RISC-V -march=rv64izcmp (https://godbolt.org/z/8dxT3nxs9), but fails when -flto is added (https://godbolt.org/z/GK5ohKnK9).

See

llvm-project/llvm/lib/Object/ModuleSymbolTable.cpp

Line 91 in eb38edc

T->createMCSubtargetInfo(TT.str(), "", ""));

[llvmbot]

@llvm/issue-subscribers-bug

The scan of module-level inline assembly performed to extract the referenced symbols does not forward the CPU specified on the clang command line. Because of this, opcodes that are only legal in that CPU will cause the compile to fail in `-flto` where it would have succeeded without. For example:

asm(".globl func; func: cm.mvsa01 s1, s0; ret");

This succeeds when compiled for RISC-V -march=rv64izcmp (https://godbolt.org/z/8dxT3nxs9), but fails when -flto is added (https://godbolt.org/z/GK5ohKnK9).

See

llvm-project/llvm/lib/Object/ModuleSymbolTable.cpp

Line 91 in eb38edc

T->createMCSubtargetInfo(TT.str(), "", ""));

[ilovepi]

@mysterymath did we ever determine what the fix would be here? IIRC it was to just use the asm scanning logic in clang, and have it emit the symbol table? at least that's my take away from https://discourse.llvm.org/t/rfc-target-cpu-and-features-for-module-level-inline-assembly/74713

[mysterymath]

@mysterymath did we ever determine what the fix would be here? IIRC it was to just use the asm scanning logic in clang, and have it emit the symbol table? at least that's my take away from https://discourse.llvm.org/t/rfc-target-cpu-and-features-for-module-level-inline-assembly/74713

Yeah, I think that's still the good move. I think it would also be ideal for this list to be attached to inline assembly constructs in the IR, too. It's a huge wart that there are differences in behavior between the two. Plus, like jyknight mentioned, this would make the contents of inline asm fully described by the surrounding constraints and IR attributes up until the text is expanded at the MC layer, which is much simpler to think about.