LLVM ERROR: Cannot select: intrinsic %llvm.x86.aesni.aesenc

[smsxgli]

Same error with #53097
Compile firefox 97.0.1 with thin LTO.
environment:
OS: arch linux.
llvm, clang and lld version: 13.0.1
CPU: Intel(R) Core(TM) i7-4790 CPU, haswell
CFLAGS: -march=native -mtune=native -O2 -pipe -fno-plt -fexceptions -fasynchronous-unwind-tables -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-protector-strong -fstack-clash-protection -fcf-protection
CXXFLAGS: $CFLAGS -Wp,-D_GLIBCXX_ASSERTIONS
LDFLAGS: -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now,-z,noexecstack
RUSTFLAGS: -C opt-level=2 -C target-cpu=native

Since building firefox with PGO, the first pass compiling without thin LTO, and everything is OK, but in the second pass,
with thin LTO, while linking libxul.so, compiling failed with logs below:

32:33.70 LLVM ERROR: Cannot select: intrinsic %llvm.x86.aesni.aesenc
32:33.70 PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
32:33.70 Stack dump:
32:33.70 0.	Running pass 'Function Pass Manager' on module '/build/firefox/src/firefox-97.0.1/obj/x86_64-unknown-linux-gnu/release/libgkrust.a(wgpu_hal-785fcf12e540c33d.wgpu_hal.c740af7d-cgu.0.rcgu.o at 76974238)'.
32:33.70 1.	Running pass 'X86 DAG->DAG Instruction Selection' on function '@"_ZN9hashbrown3map24HashMap$LT$K$C$V$C$S$GT$7get_mut17ha3902d568de85cc9E"'
32:33.94  #0 0x00007fb5a629eea7 (/usr/lib/libLLVM-13.so+0xba6ea7)
32:33.94  #1 0x00007fb5a629c6a6 (/usr/lib/libLLVM-13.so+0xba46a6)
32:33.94  #2 0x00007fb5a5305560 __restore_rt libc_sigaction.c:0:0
32:33.94  #3 0x00007fb5a535234c __pthread_kill_implementation pthread_kill.c:0:0
32:33.94  #4 0x00007fb5a53054b8 gsignal (/usr/lib/libc.so.6+0x424b8)
32:33.94  #5 0x00007fb5a52ef534 abort (/usr/lib/libc.so.6+0x2c534)
32:33.94  #6 0x00007fb5a61b8858 llvm::report_fatal_error(llvm::Twine const&, bool) (/usr/lib/libLLVM-13.so+0xac0858)
32:33.94  #7 0x00007fb5a61b89b4 (/usr/lib/libLLVM-13.so+0xac09b4)
32:33.94  #8 0x00007fb5a6c10e65 llvm::SelectionDAGISel::CannotYetSelect(llvm::SDNode*) (/usr/lib/libLLVM-13.so+0x1518e65)
32:33.94  #9 0x00007fb5a6c1229a llvm::SelectionDAGISel::SelectCodeCommon(llvm::SDNode*, unsigned char const*, unsigned int) (/usr/lib/libLLVM-13.so+0x151a29a)
32:33.94 #10 0x00007fb5a93b5f70 (/usr/lib/libLLVM-13.so+0x3cbdf70)
32:33.94 #11 0x00007fb5a6c0f9a7 llvm::SelectionDAGISel::DoInstructionSelection() (/usr/lib/libLLVM-13.so+0x15179a7)
32:33.94 #12 0x00007fb5a6c18749 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/usr/lib/libLLVM-13.so+0x1520749)
32:33.94 #13 0x00007fb5a6c1b62f llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/usr/lib/libLLVM-13.so+0x152362f)
32:33.94 #14 0x00007fb5a6c1df82 (/usr/lib/libLLVM-13.so+0x1525f82)
32:33.94 #15 0x00007fb5a93bfcc0 (/usr/lib/libLLVM-13.so+0x3cc7cc0)
32:33.94 #16 0x00007fb5a66cc1d9 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/usr/lib/libLLVM-13.so+0xfd41d9)
32:33.94 #17 0x00007fb5a6404f50 llvm::FPPassManager::runOnFunction(llvm::Function&) (/usr/lib/libLLVM-13.so+0xd0cf50)
32:33.94 #18 0x00007fb5a64050c4 llvm::FPPassManager::runOnModule(llvm::Module&) (/usr/lib/libLLVM-13.so+0xd0d0c4)
32:33.94 #19 0x00007fb5a6406a0a llvm::legacy::PassManagerImpl::run(llvm::Module&) (/usr/lib/libLLVM-13.so+0xd0ea0a)
32:33.94 #20 0x00007fb5a7c451b4 (/usr/lib/libLLVM-13.so+0x254d1b4)
32:33.94 #21 0x00007fb5a7c46404 llvm::lto::thinBackend(llvm::lto::Config const&, unsigned int, std::function<std::unique_ptr<llvm::lto::NativeObjectStream, std::default_delete<llvm::lto::NativeObjectStream> > (unsigned int)>, llvm::Module&, llvm::ModuleSummaryIndex const&, llvm::StringMap<std::unordered_set<unsigned long, std::hash<unsigned long>, std::equal_to<unsigned long>, std::allocator<unsigned long> >, llvm::MallocAllocator> const&, llvm::DenseMap<unsigned long, llvm::GlobalValueSummary*, llvm::DenseMapInfo<unsigned long>, llvm::detail::DenseMapPair<unsigned long, llvm::GlobalValueSummary*> > const&, llvm::MapVector<llvm::StringRef, llvm::BitcodeModule, llvm::DenseMap<llvm::StringRef, unsigned int, llvm::DenseMapInfo<llvm::StringRef>, llvm::detail::DenseMapPair<llvm::StringRef, unsigned int> >, std::vector<std::pair<llvm::StringRef, llvm::BitcodeModule>, std::allocator<std::pair<llvm::StringRef, llvm::BitcodeModule> > > >*, std::vector<unsigned char, std::allocator<unsigned char> > const&) (/usr/lib/libLLVM-13.so+0x254e404)
32:33.94 #22 0x00007fb5a7c2e50b (/usr/lib/libLLVM-13.so+0x253650b)
32:33.94 #23 0x00007fb5a621f786 (/usr/lib/libLLVM-13.so+0xb27786)
32:33.94 #24 0x00007fb5a61f8b6d (/usr/lib/libLLVM-13.so+0xb00b6d)
32:33.94 #25 0x00007fb5a5355788 __pthread_once_slow pthread_once.c:0:0
32:33.94 #26 0x00007fb5a62214a0 (/usr/lib/libLLVM-13.so+0xb294a0)
32:33.94 #27 0x00007fb5a53505c2 start_thread pthread_create.c:0:0
32:33.94 #28 0x00007fb5a53d5584 __clone (/usr/lib/libc.so.6+0x112584)
32:34.17 clang-13: error: unable to execute command: Aborted (core dumped)
32:34.17 clang-13: error: linker command failed due to signal (use -v to see invocation)

I am afraid that this question exist since llvm 12.

What's more, I have an laptop with Intel(R) Core(TM) i7-11800H CPU, which is tiger lake architecture, while building this with same configuration (I am quiet sure about it, since I build them in "clean build" , so called in arch development, using systemd-nspawn to get a clean build root), and no error like this.

I open a new issue here because i do not know to reopen #53097.
@phoebewang

[smsxgli]

And same error in freebsd can be found here

[llvmbot]

@llvm/issue-subscribers-backend-x86

[dongAxis]

could you provide the LLVM IR for this case? it might be easier for us to reproduce the case.

[smsxgli]

Well, since I am not familiar with LLVM, so please wait a moment and I will find out how to generate IR in this case.

[smsxgli]

After some googling, I append -Wl,-save-temps to the LDFLAGS, so while compiling, lld will generate bit code files as well as other binary files, right? So, is that helpful? Or there may be other more effective method? Please let me know, thanks! @dongAxis

[smsxgli]

Finally I generate some bit code files in the second build pass, I mean the PGO pass. I will first post all .bc files of libgkrust.a(wgpu_hal-785fcf12e540c33d.wgpu_hal.c740af7d-cgu.0.rcgu.o...), and then other .bc files.

[phoebewang]

Maybe you can try to compile these .bc with llc to see if the error can be reproduced? Then you can use llvm-reduce or bugpoint to reduce the bc file.

[smsxgli]

I am afraid I can not do that now. You see, the error occurred in linking, and the module where LLVM failed, the libgkrust.a(wgpu_hal-785fcf12e540c33d.wgpu_hal.c740af7d-cgu.0.rcgu.o at 76974238), do not generate a bit code file. Maybe I will google again for how to recompile .bc generated in LTO time.
EDIT: OK, I got it. Doing now

[smsxgli]

libgkrust_wgpu_hal.tar.zst.gz

[smsxgli]

Well, I ran the LLC, and now it repeating report <llc><crash>, so I killed it. Any other idea please? @phoebewang

[smsxgli]

bugpoint-reduced-function.bc.tar.gz
Seems this is the reduced .bc file? Although the bugpoint still output <llc><crash>, so I am not sure about it.

[phoebewang]

It's expected. It may take a long time if the bc file is too large. You can use

llvm-extract --func="_ZN9hashbrown3map24HashMap$LT$K$C$V$C$S$GT$7get_mut17ha3902d568de85cc9E" You.bc -o New.bc

for pre-process. And run bugpoint with New.bc

[smsxgli]

Got it. But llvm-extract complained llvm-extract: program doesn't contain function named '_ZN9hashbrown3map24HashMapget_mut17ha3902d568de85cc9E'!. Maybe I have to wait bugpoint for a long time.

[phoebewang]

Never mind, I can see the problem in your reduced bc file.

llvm-dis bugpoint-reduced-function.bc
vim bugpoint-reduced-function.ll

find this line
attributes #10 = { cold inlinehint nofree nosync nounwind nonlazybind "probe-stack"="__rust_probestack" "target-cpu"="haswell" }
and change to
attributes #10 = { cold inlinehint nofree nosync nounwind nonlazybind "probe-stack"="__rust_probestack" "target-cpu"="haswell" "target-features"="+aes" }
Then the compilation passed.
This is not a problem of backend. We always make sure we generate the instruction with corresponding features.
Is this IR created by rust? In Clang, we check the feature before we generate the intrinsic in IR. So that user can know the options they are missing. It looks to me the rust doesn't have the check?

[smsxgli]

I know a little about rust. but i know wgpu_hal is a rust crate.

[smsxgli]

So this is a bug of rustc?

[phoebewang]

Me either. But I guess so. Missing the features check before generating target specific intrinsics in FE looks a bug to me.

[smsxgli]

OK, So I will post this to rust's issue. And Thanks a lot! @phoebewang

[fhahn]

IIUC this is a rustc issue. There is a fix underway in rustc and nothing to fix on the LLVM side, so I am closing this issue. Please comment/re-open if I missed something.