Error from RISC-V inline asm for missing target feature despite enabling target feature when using LTO

[ilovepi]

When compiling a file for LTO/ThinLTO, we ran into an issue where an inline assembly directive for compressed instruction gave an error, despite us setting the march string correctly. Note, this occurs when generating the bitcode output in the compile step, and not during the link. We also don't see any such error in the non-LTO cases. This still occurs at ToT (1d14323) and back at least as far as c58bc24. I haven't checked farther back in the commit history than Fuchsia's previous toolchain, but I think this is probably not a new behavior/bug.

I confirmed that -target-feature +c appears in the cc1 command line.

I was able to reduce this down to just an asm(c.ebreak) statement. I've included the original file along w/ the reduced case, and reproducer script w/ a -cc1 invocation.

This code come from Fuchsia and can be found here: https://cs.opensource.google/fuchsia/fuchsia/+/main:zircon/system/utest/inspector/print_debug_info.cc;l=131?q=print_debug_info.cc&ss=fuchsia%2Ffuchsia

Failing bot: https://ci.chromium.org/ui/p/turquoise/builders/global.ci/minimal.riscv64-lto/b8757351392559542993/overview

reproducer.zip

This seems related to #67698, but I'm not totally sure. There were also some recent changes that tried to plumb these to the MC layer and I thought AsmParser, but I'm also unsure if these are related.

[llvmbot]

@llvm/issue-subscribers-bug

Author: Paul Kirth (ilovepi)

When compiling a file for LTO/ThinLTO, we ran into an issue where an inline assembly directive for compressed instruction gave an error, despite us setting the `march` string correctly. Note, this occurs when generating the bitcode output in the compile step, and not during the link. We also don't see any such error in the non-LTO cases. This still occurs at ToT (1d14323) and back at least as far as c58bc24. I haven't checked farther back in the commit history than Fuchsia's previous toolchain, but I think this is probably not a new behavior/bug.

I confirmed that -target-feature +c appears in the cc1 command line.

I was able to reduce this down to just an asm(c.ebreak) statement. I've included the original file along w/ the reduced case, and reproducer script w/ a -cc1 invocation.

This code come from Fuchsia and can be found here: https://cs.opensource.google/fuchsia/fuchsia/+/main:zircon/system/utest/inspector/print_debug_info.cc;l=131?q=print_debug_info.cc&ss=fuchsia%2Ffuchsia

Failing bot: https://ci.chromium.org/ui/p/turquoise/builders/global.ci/minimal.riscv64-lto/b8757351392559542993/overview

reproducer.zip

This seems related to #67698, but I'm not totally sure. There were also some recent changes that tried to plumb these to the MC layer and I thought AsmParser, but I'm also unsure if these are related.

[llvmbot]

@llvm/issue-subscribers-backend-risc-v

Author: Paul Kirth (ilovepi)

When compiling a file for LTO/ThinLTO, we ran into an issue where an inline assembly directive for compressed instruction gave an error, despite us setting the `march` string correctly. Note, this occurs when generating the bitcode output in the compile step, and not during the link. We also don't see any such error in the non-LTO cases. This still occurs at ToT (1d14323) and back at least as far as c58bc24. I haven't checked farther back in the commit history than Fuchsia's previous toolchain, but I think this is probably not a new behavior/bug.

I confirmed that -target-feature +c appears in the cc1 command line.

I was able to reduce this down to just an asm(c.ebreak) statement. I've included the original file along w/ the reduced case, and reproducer script w/ a -cc1 invocation.

This code come from Fuchsia and can be found here: https://cs.opensource.google/fuchsia/fuchsia/+/main:zircon/system/utest/inspector/print_debug_info.cc;l=131?q=print_debug_info.cc&ss=fuchsia%2Ffuchsia

Failing bot: https://ci.chromium.org/ui/p/turquoise/builders/global.ci/minimal.riscv64-lto/b8757351392559542993/overview

reproducer.zip

This seems related to #67698, but I'm not totally sure. There were also some recent changes that tried to plumb these to the MC layer and I thought AsmParser, but I'm also unsure if these are related.

[MaskRay]

I think this is #67698 , for module-level inline assembly.
See also https://discourse.llvm.org/t/rfc-target-cpu-and-features-for-module-level-inline-assembly/74713