Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LLVM 18 regression: SelectionDAG/LegalizeDAG.cpp:991: void {anonymous}::SelectionDAGLegalize::LegalizeOp(llvm::SDNode*): Assertion `(TLI.getTypeAction(*DAG.getContext(), Op.getValueType()) == TargetLowering::TypeLegal || Op.getOpcode() == ISD::TargetConstant || Op.getOpcode() == ISD::Register) && "Unexpected illegal type!"' failed #90356

Closed
andrewrk opened this issue Apr 27, 2024 · 19 comments · Fixed by #90390
Labels
backend:X86 bug Indicates an unexpected problem or unintended behavior regression

Comments

@andrewrk
Copy link
Member

andrewrk commented Apr 27, 2024

version: LLVM 18.x branch (commit 78b99c7)

The Zig compiler fails to build from source after updating to LLVM 18.

reduced.ll:

target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

define fastcc void @"fmt.parse_float.decimal.Decimal(f16).leftShift"() #0 {
  br label %1

1:                                                ; preds = %7, %2, %0
  %.sroa.02.0 = phi i64 [ 0, %0 ], [ -1, %7 ], [ %4, %2 ]
  %.sroa.0.0 = phi i64 [ 1, %0 ], [ %3, %7 ], [ %3, %2 ]
  %.not = icmp eq i64 %.sroa.0.0, 0
  br i1 %.not, label %6, label %2

2:                                                ; preds = %1
  %3 = add i64 %.sroa.0.0, 1
  %4 = add i64 %.sroa.02.0, -1
  %5 = icmp eq i64 %.sroa.02.0, 0
  br i1 %5, label %7, label %1

6:                                                ; preds = %1
  ret void

7:                                                ; preds = %2
  %8 = getelementptr [768 x i8], ptr null, i64 0, i64 %4
  store i8 0, ptr %8, align 1
  br label %1

; uselistorder directives
  uselistorder i64 %3, { 1, 0 }
}

attributes #0 = { "target-features"="-16bit-mode,-32bit-mode,-3dnow,-3dnowa,+64bit,+adx,+aes,+allow-light-256-bit,-amx-bf16,-amx-complex,-amx-fp16,-amx-int8,-amx-tile,+avx,-avx10.1-256,-avx10.1-512,+avx2,+avx512bf16,+avx512bitalg,+avx512bw,+avx512cd,+avx512dq,-avx512er,+avx512f,-avx512fp16,+avx512ifma,-avx512pf,+avx512vbmi,+avx512vbmi2,+avx512vl,+avx512vnni,-avx512vp2intersect,+avx512vpopcntdq,-avxifma,-avxneconvert,-avxvnni,-avxvnniint16,-avxvnniint8,+bmi,+bmi2,+branchfusion,-ccmp,-cf,-cldemote,+clflushopt,+clwb,+clzero,+cmov,-cmpccxadd,+crc32,+cx16,+cx8,-egpr,-enqcmd,-ermsb,-evex512,+f16c,-false-deps-getmant,-false-deps-lzcnt-tzcnt,-false-deps-mulc,-false-deps-mullq,-false-deps-perm,-false-deps-popcnt,-false-deps-range,-fast-11bytenop,+fast-15bytenop,-fast-7bytenop,+fast-bextr,-fast-gather,-fast-hops,+fast-lzcnt,+fast-movbe,+fast-scalar-fsqrt,+fast-scalar-shift-masks,-fast-shld-rotate,-fast-variable-crosslane-shuffle,+fast-variable-perlane-shuffle,+fast-vector-fsqrt,-fast-vector-shift-masks,-faster-shift-than-shuffle,+fma,-fma4,+fsgsbase,+fsrm,+fxsr,+gfni,-harden-sls-ijmp,-harden-sls-ret,-hreset,-idivl-to-divb,-idivq-to-divl,+invpcid,-kl,-lea-sp,-lea-uses-ag,-lvi-cfi,-lvi-load-hardening,-lwp,+lzcnt,+macrofusion,+mmx,+movbe,-movdir64b,-movdiri,+mwaitx,-ndd,-no-bypass-delay,-no-bypass-delay-blend,-no-bypass-delay-mov,-no-bypass-delay-shuffle,+nopl,-pad-short-functions,+pclmul,-pconfig,+pku,+popcnt,-ppx,-prefer-128-bit,-prefer-256-bit,-prefer-mask-registers,-prefer-movmsk-over-vtest,-prefer-no-gather,-prefer-no-scatter,-prefetchi,-prefetchwt1,+prfchw,-ptwrite,-push2pop2,-raoint,+rdpid,+rdpru,+rdrnd,+rdseed,-retpoline,-retpoline-external-thunk,-retpoline-indirect-branches,-retpoline-indirect-calls,-rtm,+sahf,+sbb-dep-breaking,-serialize,-seses,-sgx,+sha,-sha512,+shstk,-slow-3ops-lea,-slow-incdec,-slow-lea,-slow-pmaddwd,-slow-pmulld,+slow-shld,-slow-two-mem-ops,-slow-unaligned-mem-16,-slow-unaligned-mem-32,-sm3,-sm4,-soft-float,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+sse4a,-sse-unaligned-mem,+ssse3,-tagged-globals,-tbm,-tsxldtrk,-tuning-fast-imm-vector-shift,-uintr,-use-glm-div-sqrt-costs,-use-slm-arith-costs,-usermsr,+vaes,+vpclmulqdq,+vzeroupper,-waitpkg,+wbnoinvd,-widekl,+x87,-xop,+xsave,+xsavec,+xsaveopt,+xsaves" }
[nix-shell:~/src/zig/build-llvm18-release]$ ~/local/llvm18-assert/bin/clang -c reduced.ll -O3
clang: /home/andy/dev/llvm-project-18/llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:991: void {anonymous}::SelectionDAGLegalize::LegalizeOp(llvm::SDNode*): Assertion `(TLI.getTypeAction(*DAG.getContext(), Op.getValueType()) == TargetLowering::TypeLegal || Op.getOpcode() == ISD::TargetConstant || Op.getOpcode() == ISD::Register) && "Unexpected illegal type!"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.      Program arguments: /home/andy/local/llvm18-assert/bin/clang -c reduced.ll -O3
1.      Code generation
2.      Running pass 'Function Pass Manager' on module 'reduced.ll'.
3.      Running pass 'X86 DAG->DAG Instruction Selection' on function '@"fmt.parse_float.decimal.Decimal(f16).leftShift"'
 #0 0x000000000387f4db llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/andy/local/llvm18-assert/bin/clang+0x387f4db)
 #1 0x000000000387c83b llvm::sys::RunSignalHandlers() (/home/andy/local/llvm18-assert/bin/clang+0x387c83b)
 #2 0x00000000037c1508 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
 #3 0x00007f2075454a70 __restore_rt (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x3da70)
 #4 0x00007f20754a3ddc __pthread_kill_implementation (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x8cddc)
 #5 0x00007f20754549c6 gsignal (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x3d9c6)
 #6 0x00007f207543d8fa abort (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x268fa)
 #7 0x00007f207543d819 _nl_load_domain.cold (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x26819)
 #8 0x00007f207544d3c6 (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x363c6)
 #9 0x00000000048a69fa (anonymous namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDNode*) LegalizeDAG.cpp:0:0
#10 0x00000000048b3100 llvm::SelectionDAG::Legalize() (/home/andy/local/llvm18-assert/bin/clang+0x48b3100)
#11 0x000000000499c826 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/home/andy/local/llvm18-assert/bin/clang+0x499c826)
#12 0x00000000049a06ac llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/home/andy/local/llvm18-assert/bin/clang+0x49a06ac)
#13 0x00000000049a2257 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (.part.0) SelectionDAGISel.cpp:0:0
#14 0x0000000002409ff5 (anonymous namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) X86ISelDAGToDAG.cpp:0:0
#15 0x0000000002c30325 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.0) MachineFunctionPass.cpp:0:0
#16 0x0000000003213619 llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/andy/local/llvm18-assert/bin/clang+0x3213619)
#17 0x0000000003213751 llvm::FPPassManager::runOnModule(llvm::Module&) (/home/andy/local/llvm18-assert/bin/clang+0x3213751)
#18 0x0000000003214057 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/andy/local/llvm18-assert/bin/clang+0x3214057)
#19 0x0000000003aedb33 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr<llvm::vfs::FileSystem>, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream>>, clang::BackendConsumer*) (/home/andy/local/llvm18-assert/bin/clang+0x3aedb33)
#20 0x00000000040cd0fa clang::CodeGenAction::ExecuteAction() (/home/andy/local/llvm18-assert/bin/clang+0x40cd0fa)
#21 0x000000000434b2c9 clang::FrontendAction::Execute() (/home/andy/local/llvm18-assert/bin/clang+0x434b2c9)
#22 0x00000000042d0c02 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/home/andy/local/llvm18-assert/bin/clang+0x42d0c02)
#23 0x000000000441906f clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/home/andy/local/llvm18-assert/bin/clang+0x441906f)
#24 0x0000000000b7b6ca cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/home/andy/local/llvm18-assert/bin/clang+0xb7b6ca)
#25 0x0000000000b736a7 ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&, llvm::ToolContext const&) driver.cpp:0:0
#26 0x000000000410e509 void llvm::function_ref<void ()>::callback_fn<clang::driver::CC1Command::Execute(llvm::ArrayRef<std::optional<llvm::StringRef>>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>*, bool*) const::'lambda'()>(long) Job.cpp:0:0
#27 0x00000000037c1962 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) (/home/andy/local/llvm18-assert/bin/clang+0x37c1962)
#28 0x000000000410fbf4 clang::driver::CC1Command::Execute(llvm::ArrayRef<std::optional<llvm::StringRef>>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>*, bool*) const (.part.0) Job.cpp:0:0
#29 0x00000000040d6ae5 clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&, bool) const (/home/andy/local/llvm18-assert/bin/clang+0x40d6ae5)
#30 0x00000000040d75dd clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&, bool) const (/home/andy/local/llvm18-assert/bin/clang+0x40d75dd)
#31 0x00000000040e1bb4 clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&) (/home/andy/local/llvm18-assert/bin/clang+0x40e1bb4)
#32 0x0000000000b78d69 clang_main(int, char**, llvm::ToolContext const&) (/home/andy/local/llvm18-assert/bin/clang+0xb78d69)
#33 0x0000000000a6feb3 main (/home/andy/local/llvm18-assert/bin/clang+0xa6feb3)
#34 0x00007f207543efce __libc_start_call_main (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x27fce)
#35 0x00007f207543f089 __libc_start_main@GLIBC_2.2.5 (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x28089)
#36 0x0000000000b72315 _start (/home/andy/local/llvm18-assert/bin/clang+0xb72315)
clang: error: clang frontend command failed with exit code 134 (use -v to see invocation)
clang version 18.1.5 (https://github.com/llvm/llvm-project 78b99c73ee4b96fe9ce0e294d4632326afb2db42)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/andy/local/llvm18-assert/bin
clang: note: diagnostic msg: Error generating preprocessed source(s) - no preprocessable inputs.
@andrewrk andrewrk added bug Indicates an unexpected problem or unintended behavior regression labels Apr 27, 2024
@andrewrk andrewrk added this to the LLVM 18.X Release milestone Apr 27, 2024
@llvmbot
Copy link
Collaborator

llvmbot commented Apr 27, 2024

@llvm/issue-subscribers-bug

Author: Andrew Kelley (andrewrk)

version: LLVM 18.x branch (commit 78b99c7)

The Zig compiler fails to build from source after updating to LLVM 18.

reduced.ll:

target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

define fastcc void @"fmt.parse_float.decimal.Decimal(f16).leftShift"() #<!-- -->0 {
  br label %1

1:                                                ; preds = %7, %2, %0
  %.sroa.02.0 = phi i64 [ 0, %0 ], [ -1, %7 ], [ %4, %2 ]
  %.sroa.0.0 = phi i64 [ 1, %0 ], [ %3, %7 ], [ %3, %2 ]
  %.not = icmp eq i64 %.sroa.0.0, 0
  br i1 %.not, label %6, label %2

2:                                                ; preds = %1
  %3 = add i64 %.sroa.0.0, 1
  %4 = add i64 %.sroa.02.0, -1
  %5 = icmp eq i64 %.sroa.02.0, 0
  br i1 %5, label %7, label %1

6:                                                ; preds = %1
  ret void

7:                                                ; preds = %2
  %8 = getelementptr [768 x i8], ptr null, i64 0, i64 %4
  store i8 0, ptr %8, align 1
  br label %1

; uselistorder directives
  uselistorder i64 %3, { 1, 0 }
}

attributes #<!-- -->0 = { "target-features"="-16bit-mode,-32bit-mode,-3dnow,-3dnowa,+64bit,+adx,+aes,+allow-light-256-bit,-amx-bf16,-amx-complex,-amx-fp16,-amx-int8,-amx-tile,+avx,-avx10.1-256,-avx10.1-512,+avx2,+avx512bf16,+avx512bitalg,+avx512bw,+avx512cd,+avx512dq,-avx512er,+avx512f,-avx512fp16,+avx512ifma,-avx512pf,+avx512vbmi,+avx512vbmi2,+avx512vl,+avx512vnni,-avx512vp2intersect,+avx512vpopcntdq,-avxifma,-avxneconvert,-avxvnni,-avxvnniint16,-avxvnniint8,+bmi,+bmi2,+branchfusion,-ccmp,-cf,-cldemote,+clflushopt,+clwb,+clzero,+cmov,-cmpccxadd,+crc32,+cx16,+cx8,-egpr,-enqcmd,-ermsb,-evex512,+f16c,-false-deps-getmant,-false-deps-lzcnt-tzcnt,-false-deps-mulc,-false-deps-mullq,-false-deps-perm,-false-deps-popcnt,-false-deps-range,-fast-11bytenop,+fast-15bytenop,-fast-7bytenop,+fast-bextr,-fast-gather,-fast-hops,+fast-lzcnt,+fast-movbe,+fast-scalar-fsqrt,+fast-scalar-shift-masks,-fast-shld-rotate,-fast-variable-crosslane-shuffle,+fast-variable-perlane-shuffle,+fast-vector-fsqrt,-fast-vector-shift-masks,-faster-shift-than-shuffle,+fma,-fma4,+fsgsbase,+fsrm,+fxsr,+gfni,-harden-sls-ijmp,-harden-sls-ret,-hreset,-idivl-to-divb,-idivq-to-divl,+invpcid,-kl,-lea-sp,-lea-uses-ag,-lvi-cfi,-lvi-load-hardening,-lwp,+lzcnt,+macrofusion,+mmx,+movbe,-movdir64b,-movdiri,+mwaitx,-ndd,-no-bypass-delay,-no-bypass-delay-blend,-no-bypass-delay-mov,-no-bypass-delay-shuffle,+nopl,-pad-short-functions,+pclmul,-pconfig,+pku,+popcnt,-ppx,-prefer-128-bit,-prefer-256-bit,-prefer-mask-registers,-prefer-movmsk-over-vtest,-prefer-no-gather,-prefer-no-scatter,-prefetchi,-prefetchwt1,+prfchw,-ptwrite,-push2pop2,-raoint,+rdpid,+rdpru,+rdrnd,+rdseed,-retpoline,-retpoline-external-thunk,-retpoline-indirect-branches,-retpoline-indirect-calls,-rtm,+sahf,+sbb-dep-breaking,-serialize,-seses,-sgx,+sha,-sha512,+shstk,-slow-3ops-lea,-slow-incdec,-slow-lea,-slow-pmaddwd,-slow-pmulld,+slow-shld,-slow-two-mem-ops,-slow-unaligned-mem-16,-slow-unaligned-mem-32,-sm3,-sm4,-soft-float,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+sse4a,-sse-unaligned-mem,+ssse3,-tagged-globals,-tbm,-tsxldtrk,-tuning-fast-imm-vector-shift,-uintr,-use-glm-div-sqrt-costs,-use-slm-arith-costs,-usermsr,+vaes,+vpclmulqdq,+vzeroupper,-waitpkg,+wbnoinvd,-widekl,+x87,-xop,+xsave,+xsavec,+xsaveopt,+xsaves" }
[nix-shell:~/src/zig/build-llvm18-release]$ ~/local/llvm18-assert/bin/clang -c reduced.ll -O3
clang: /home/andy/dev/llvm-project-18/llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:991: void {anonymous}::SelectionDAGLegalize::LegalizeOp(llvm::SDNode*): Assertion `(TLI.getTypeAction(*DAG.getContext(), Op.getValueType()) == TargetLowering::TypeLegal || Op.getOpcode() == ISD::TargetConstant || Op.getOpcode() == ISD::Register) &amp;&amp; "Unexpected illegal type!"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.      Program arguments: /home/andy/local/llvm18-assert/bin/clang -c reduced.ll -O3
1.      Code generation
2.      Running pass 'Function Pass Manager' on module 'reduced.ll'.
3.      Running pass 'X86 DAG-&gt;DAG Instruction Selection' on function '@"fmt.parse_float.decimal.Decimal(f16).leftShift"'
 #<!-- -->0 0x000000000387f4db llvm::sys::PrintStackTrace(llvm::raw_ostream&amp;, int) (/home/andy/local/llvm18-assert/bin/clang+0x387f4db)
 #<!-- -->1 0x000000000387c83b llvm::sys::RunSignalHandlers() (/home/andy/local/llvm18-assert/bin/clang+0x387c83b)
 #<!-- -->2 0x00000000037c1508 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
 #<!-- -->3 0x00007f2075454a70 __restore_rt (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x3da70)
 #<!-- -->4 0x00007f20754a3ddc __pthread_kill_implementation (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x8cddc)
 #<!-- -->5 0x00007f20754549c6 gsignal (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x3d9c6)
 #<!-- -->6 0x00007f207543d8fa abort (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x268fa)
 #<!-- -->7 0x00007f207543d819 _nl_load_domain.cold (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x26819)
 #<!-- -->8 0x00007f207544d3c6 (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x363c6)
 #<!-- -->9 0x00000000048a69fa (anonymous namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDNode*) LegalizeDAG.cpp:0:0
#<!-- -->10 0x00000000048b3100 llvm::SelectionDAG::Legalize() (/home/andy/local/llvm18-assert/bin/clang+0x48b3100)
#<!-- -->11 0x000000000499c826 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/home/andy/local/llvm18-assert/bin/clang+0x499c826)
#<!-- -->12 0x00000000049a06ac llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&amp;) (/home/andy/local/llvm18-assert/bin/clang+0x49a06ac)
#<!-- -->13 0x00000000049a2257 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&amp;) (.part.0) SelectionDAGISel.cpp:0:0
#<!-- -->14 0x0000000002409ff5 (anonymous namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&amp;) X86ISelDAGToDAG.cpp:0:0
#<!-- -->15 0x0000000002c30325 llvm::MachineFunctionPass::runOnFunction(llvm::Function&amp;) (.part.0) MachineFunctionPass.cpp:0:0
#<!-- -->16 0x0000000003213619 llvm::FPPassManager::runOnFunction(llvm::Function&amp;) (/home/andy/local/llvm18-assert/bin/clang+0x3213619)
#<!-- -->17 0x0000000003213751 llvm::FPPassManager::runOnModule(llvm::Module&amp;) (/home/andy/local/llvm18-assert/bin/clang+0x3213751)
#<!-- -->18 0x0000000003214057 llvm::legacy::PassManagerImpl::run(llvm::Module&amp;) (/home/andy/local/llvm18-assert/bin/clang+0x3214057)
#<!-- -->19 0x0000000003aedb33 clang::EmitBackendOutput(clang::DiagnosticsEngine&amp;, clang::HeaderSearchOptions const&amp;, clang::CodeGenOptions const&amp;, clang::TargetOptions const&amp;, clang::LangOptions const&amp;, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr&lt;llvm::vfs::FileSystem&gt;, std::unique_ptr&lt;llvm::raw_pwrite_stream, std::default_delete&lt;llvm::raw_pwrite_stream&gt;&gt;, clang::BackendConsumer*) (/home/andy/local/llvm18-assert/bin/clang+0x3aedb33)
#<!-- -->20 0x00000000040cd0fa clang::CodeGenAction::ExecuteAction() (/home/andy/local/llvm18-assert/bin/clang+0x40cd0fa)
#<!-- -->21 0x000000000434b2c9 clang::FrontendAction::Execute() (/home/andy/local/llvm18-assert/bin/clang+0x434b2c9)
#<!-- -->22 0x00000000042d0c02 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&amp;) (/home/andy/local/llvm18-assert/bin/clang+0x42d0c02)
#<!-- -->23 0x000000000441906f clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/home/andy/local/llvm18-assert/bin/clang+0x441906f)
#<!-- -->24 0x0000000000b7b6ca cc1_main(llvm::ArrayRef&lt;char const*&gt;, char const*, void*) (/home/andy/local/llvm18-assert/bin/clang+0xb7b6ca)
#<!-- -->25 0x0000000000b736a7 ExecuteCC1Tool(llvm::SmallVectorImpl&lt;char const*&gt;&amp;, llvm::ToolContext const&amp;) driver.cpp:0:0
#<!-- -->26 0x000000000410e509 void llvm::function_ref&lt;void ()&gt;::callback_fn&lt;clang::driver::CC1Command::Execute(llvm::ArrayRef&lt;std::optional&lt;llvm::StringRef&gt;&gt;, std::__cxx11::basic_string&lt;char, std::char_traits&lt;char&gt;, std::allocator&lt;char&gt;&gt;*, bool*) const::'lambda'()&gt;(long) Job.cpp:0:0
#<!-- -->27 0x00000000037c1962 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref&lt;void ()&gt;) (/home/andy/local/llvm18-assert/bin/clang+0x37c1962)
#<!-- -->28 0x000000000410fbf4 clang::driver::CC1Command::Execute(llvm::ArrayRef&lt;std::optional&lt;llvm::StringRef&gt;&gt;, std::__cxx11::basic_string&lt;char, std::char_traits&lt;char&gt;, std::allocator&lt;char&gt;&gt;*, bool*) const (.part.0) Job.cpp:0:0
#<!-- -->29 0x00000000040d6ae5 clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&amp;, clang::driver::Command const*&amp;, bool) const (/home/andy/local/llvm18-assert/bin/clang+0x40d6ae5)
#<!-- -->30 0x00000000040d75dd clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&amp;, llvm::SmallVectorImpl&lt;std::pair&lt;int, clang::driver::Command const*&gt;&gt;&amp;, bool) const (/home/andy/local/llvm18-assert/bin/clang+0x40d75dd)
#<!-- -->31 0x00000000040e1bb4 clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&amp;, llvm::SmallVectorImpl&lt;std::pair&lt;int, clang::driver::Command const*&gt;&gt;&amp;) (/home/andy/local/llvm18-assert/bin/clang+0x40e1bb4)
#<!-- -->32 0x0000000000b78d69 clang_main(int, char**, llvm::ToolContext const&amp;) (/home/andy/local/llvm18-assert/bin/clang+0xb78d69)
#<!-- -->33 0x0000000000a6feb3 main (/home/andy/local/llvm18-assert/bin/clang+0xa6feb3)
#<!-- -->34 0x00007f207543efce __libc_start_call_main (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x27fce)
#<!-- -->35 0x00007f207543f089 __libc_start_main@<!-- -->GLIBC_2.2.5 (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x28089)
#<!-- -->36 0x0000000000b72315 _start (/home/andy/local/llvm18-assert/bin/clang+0xb72315)
clang: error: clang frontend command failed with exit code 134 (use -v to see invocation)
clang version 18.1.5 (https://github.com/llvm/llvm-project 78b99c73ee4b96fe9ce0e294d4632326afb2db42)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/andy/local/llvm18-assert/bin
clang: note: diagnostic msg: Error generating preprocessed source(s) - no preprocessable inputs.

@andrewrk
Copy link
Member Author

andrewrk commented Apr 27, 2024

Another reduction of the same assertion found by @mikdusan:

; ModuleID = 'reduced.bc'
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

define fastcc void @aro.Parser.eatIdentifier(<16 x i1> %0) #0 {
Entry:
  %1 = shufflevector <16 x i1> %0, <16 x i1> zeroinitializer, <16 x i32> <i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7, i32 8, i32 9, i32 10, i32 11, i32 28, i32 29, i32 30, i32 31>
  %2 = bitcast <16 x i1> %1 to i16
  %3 = icmp ne i16 %2, 0
  br i1 %3, label %Then21.i, label %Else.i131.i

Else.i131.i:                                      ; preds = %Entry
  %4 = icmp eq i21 0, 0
  br label %Then21.i

Then21.i:                                         ; preds = %Else.i131.i, %Entry
  ret void
}

attributes #0 = { "target-features"="-16bit-mode,-32bit-mode,-3dnow,-3dnowa,+64bit,+adx,+aes,+allow-light-256-bit,-amx-bf16,-amx-complex,-amx-fp16,-amx-int8,-amx-tile,+avx,-avx10.1-256,-avx10.1-512,+avx2,+avx512bf16,+avx512bitalg,+avx512bw,+avx512cd,+avx512dq,-avx512er,+avx512f,-avx512fp16,+avx512ifma,-avx512pf,+avx512vbmi,+avx512vbmi2,+avx512vl,+avx512vnni,-avx512vp2intersect,+avx512vpopcntdq,-avxifma,-avxneconvert,-avxvnni,-avxvnniint16,-avxvnniint8,+bmi,+bmi2,+branchfusion,-ccmp,-cf,-cldemote,+clflushopt,+clwb,+clzero,+cmov,-cmpccxadd,+crc32,+cx16,+cx8,-egpr,-enqcmd,-ermsb,-evex512,+f16c,-false-deps-getmant,-false-deps-lzcnt-tzcnt,-false-deps-mulc,-false-deps-mullq,-false-deps-perm,-false-deps-popcnt,-false-deps-range,-fast-11bytenop,+fast-15bytenop,-fast-7bytenop,+fast-bextr,-fast-gather,-fast-hops,+fast-lzcnt,+fast-movbe,+fast-scalar-fsqrt,+fast-scalar-shift-masks,-fast-shld-rotate,-fast-variable-crosslane-shuffle,+fast-variable-perlane-shuffle,+fast-vector-fsqrt,-fast-vector-shift-masks,-faster-shift-than-shuffle,+fma,-fma4,+fsgsbase,+fsrm,+fxsr,+gfni,-harden-sls-ijmp,-harden-sls-ret,-hreset,-idivl-to-divb,-idivq-to-divl,+invpcid,-kl,-lea-sp,-lea-uses-ag,-lvi-cfi,-lvi-load-hardening,-lwp,+lzcnt,+macrofusion,+mmx,+movbe,-movdir64b,-movdiri,-mwaitx,-ndd,-no-bypass-delay,-no-bypass-delay-blend,-no-bypass-delay-mov,-no-bypass-delay-shuffle,+nopl,-pad-short-functions,+pclmul,-pconfig,+pku,+popcnt,-ppx,-prefer-128-bit,-prefer-256-bit,-prefer-mask-registers,-prefer-movmsk-over-vtest,-prefer-no-gather,-prefer-no-scatter,-prefetchi,-prefetchwt1,+prfchw,-ptwrite,-push2pop2,-raoint,+rdpid,+rdpru,+rdrnd,+rdseed,-retpoline,-retpoline-external-thunk,-retpoline-indirect-branches,-retpoline-indirect-calls,-rtm,+sahf,+sbb-dep-breaking,-serialize,-seses,-sgx,+sha,-sha512,-shstk,-slow-3ops-lea,-slow-incdec,-slow-lea,-slow-pmaddwd,-slow-pmulld,+slow-shld,-slow-two-mem-ops,-slow-unaligned-mem-16,-slow-unaligned-mem-32,-sm3,-sm4,-soft-float,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+sse4a,-sse-unaligned-mem,+ssse3,-tagged-globals,-tbm,-tsxldtrk,-tuning-fast-imm-vector-shift,-uintr,-use-glm-div-sqrt-costs,-use-slm-arith-costs,-usermsr,+vaes,+vpclmulqdq,+vzeroupper,-waitpkg,+wbnoinvd,-widekl,+x87,-xop,+xsave,+xsavec,+xsaveopt,+xsaves" }
[nix-shell:~/src/zig/build-llvm18-release]$ ~/local/llvm18-assert/bin/llc ~/Downloads/reduced.ll 
llc: /home/andy/dev/llvm-project-18/llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:991: void {anonymous}::SelectionDAGLegalize::LegalizeOp(llvm::SDNode*): Assertion `(TLI.getTypeAction(*DAG.getContext(), Op.getValueType()) == TargetLowering::TypeLegal || Op.getOpcode() == ISD::TargetConstant || Op.getOpcode() == ISD::Register) && "Unexpected illegal type!"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.      Program arguments: /home/andy/local/llvm18-assert/bin/llc /home/andy/Downloads/reduced.ll
1.      Running pass 'Function Pass Manager' on module '/home/andy/Downloads/reduced.ll'.
2.      Running pass 'X86 DAG->DAG Instruction Selection' on function '@aro.Parser.eatIdentifier'
 #0 0x000000000393ec9b llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/andy/local/llvm18-assert/bin/llc+0x393ec9b)
 #1 0x000000000393bffb llvm::sys::RunSignalHandlers() (/home/andy/local/llvm18-assert/bin/llc+0x393bffb)
 #2 0x000000000393c125 SignalHandler(int) Signals.cpp:0:0
 #3 0x00007f19a7d74a70 __restore_rt (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x3da70)
 #4 0x00007f19a7dc3ddc __pthread_kill_implementation (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x8cddc)
 #5 0x00007f19a7d749c6 gsignal (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x3d9c6)
 #6 0x00007f19a7d5d8fa abort (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x268fa)
 #7 0x00007f19a7d5d819 _nl_load_domain.cold (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x26819)
 #8 0x00007f19a7d6d3c6 (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x363c6)
 #9 0x00000000035dcc6a (anonymous namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDNode*) LegalizeDAG.cpp:0:0
#10 0x00000000035e9370 llvm::SelectionDAG::Legalize() (/home/andy/local/llvm18-assert/bin/llc+0x35e9370)
#11 0x00000000036f86f6 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/home/andy/local/llvm18-assert/bin/llc+0x36f86f6)
#12 0x00000000036fc57c llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/home/andy/local/llvm18-assert/bin/llc+0x36fc57c)
#13 0x00000000036fe127 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (.part.0) SelectionDAGISel.cpp:0:0
#14 0x0000000001dd4985 (anonymous namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) X86ISelDAGToDAG.cpp:0:0
#15 0x000000000292dd25 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.0) MachineFunctionPass.cpp:0:0
#16 0x0000000002ef1789 llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/andy/local/llvm18-assert/bin/llc+0x2ef1789)
#17 0x0000000002ef18c1 llvm::FPPassManager::runOnModule(llvm::Module&) (/home/andy/local/llvm18-assert/bin/llc+0x2ef18c1)
#18 0x0000000002ef21c7 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/andy/local/llvm18-assert/bin/llc+0x2ef21c7)
#19 0x00000000007fe10b compileModule(char**, llvm::LLVMContext&) llc.cpp:0:0
#20 0x00000000007049a7 main (/home/andy/local/llvm18-assert/bin/llc+0x7049a7)
#21 0x00007f19a7d5efce __libc_start_call_main (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x27fce)
#22 0x00007f19a7d5f089 __libc_start_main@GLIBC_2.2.5 (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x28089)
#23 0x00000000007f3c25 _start (/home/andy/local/llvm18-assert/bin/llc+0x7f3c25)
Aborted (core dumped)

@EugeneZelenko EugeneZelenko added backend:X86 llvm:SelectionDAG SelectionDAGISel as well labels Apr 27, 2024
@llvmbot
Copy link
Collaborator

llvmbot commented Apr 27, 2024

@llvm/issue-subscribers-backend-x86

Author: Andrew Kelley (andrewrk)

version: LLVM 18.x branch (commit 78b99c7)

The Zig compiler fails to build from source after updating to LLVM 18.

reduced.ll:

target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

define fastcc void @"fmt.parse_float.decimal.Decimal(f16).leftShift"() #<!-- -->0 {
  br label %1

1:                                                ; preds = %7, %2, %0
  %.sroa.02.0 = phi i64 [ 0, %0 ], [ -1, %7 ], [ %4, %2 ]
  %.sroa.0.0 = phi i64 [ 1, %0 ], [ %3, %7 ], [ %3, %2 ]
  %.not = icmp eq i64 %.sroa.0.0, 0
  br i1 %.not, label %6, label %2

2:                                                ; preds = %1
  %3 = add i64 %.sroa.0.0, 1
  %4 = add i64 %.sroa.02.0, -1
  %5 = icmp eq i64 %.sroa.02.0, 0
  br i1 %5, label %7, label %1

6:                                                ; preds = %1
  ret void

7:                                                ; preds = %2
  %8 = getelementptr [768 x i8], ptr null, i64 0, i64 %4
  store i8 0, ptr %8, align 1
  br label %1

; uselistorder directives
  uselistorder i64 %3, { 1, 0 }
}

attributes #<!-- -->0 = { "target-features"="-16bit-mode,-32bit-mode,-3dnow,-3dnowa,+64bit,+adx,+aes,+allow-light-256-bit,-amx-bf16,-amx-complex,-amx-fp16,-amx-int8,-amx-tile,+avx,-avx10.1-256,-avx10.1-512,+avx2,+avx512bf16,+avx512bitalg,+avx512bw,+avx512cd,+avx512dq,-avx512er,+avx512f,-avx512fp16,+avx512ifma,-avx512pf,+avx512vbmi,+avx512vbmi2,+avx512vl,+avx512vnni,-avx512vp2intersect,+avx512vpopcntdq,-avxifma,-avxneconvert,-avxvnni,-avxvnniint16,-avxvnniint8,+bmi,+bmi2,+branchfusion,-ccmp,-cf,-cldemote,+clflushopt,+clwb,+clzero,+cmov,-cmpccxadd,+crc32,+cx16,+cx8,-egpr,-enqcmd,-ermsb,-evex512,+f16c,-false-deps-getmant,-false-deps-lzcnt-tzcnt,-false-deps-mulc,-false-deps-mullq,-false-deps-perm,-false-deps-popcnt,-false-deps-range,-fast-11bytenop,+fast-15bytenop,-fast-7bytenop,+fast-bextr,-fast-gather,-fast-hops,+fast-lzcnt,+fast-movbe,+fast-scalar-fsqrt,+fast-scalar-shift-masks,-fast-shld-rotate,-fast-variable-crosslane-shuffle,+fast-variable-perlane-shuffle,+fast-vector-fsqrt,-fast-vector-shift-masks,-faster-shift-than-shuffle,+fma,-fma4,+fsgsbase,+fsrm,+fxsr,+gfni,-harden-sls-ijmp,-harden-sls-ret,-hreset,-idivl-to-divb,-idivq-to-divl,+invpcid,-kl,-lea-sp,-lea-uses-ag,-lvi-cfi,-lvi-load-hardening,-lwp,+lzcnt,+macrofusion,+mmx,+movbe,-movdir64b,-movdiri,+mwaitx,-ndd,-no-bypass-delay,-no-bypass-delay-blend,-no-bypass-delay-mov,-no-bypass-delay-shuffle,+nopl,-pad-short-functions,+pclmul,-pconfig,+pku,+popcnt,-ppx,-prefer-128-bit,-prefer-256-bit,-prefer-mask-registers,-prefer-movmsk-over-vtest,-prefer-no-gather,-prefer-no-scatter,-prefetchi,-prefetchwt1,+prfchw,-ptwrite,-push2pop2,-raoint,+rdpid,+rdpru,+rdrnd,+rdseed,-retpoline,-retpoline-external-thunk,-retpoline-indirect-branches,-retpoline-indirect-calls,-rtm,+sahf,+sbb-dep-breaking,-serialize,-seses,-sgx,+sha,-sha512,+shstk,-slow-3ops-lea,-slow-incdec,-slow-lea,-slow-pmaddwd,-slow-pmulld,+slow-shld,-slow-two-mem-ops,-slow-unaligned-mem-16,-slow-unaligned-mem-32,-sm3,-sm4,-soft-float,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+sse4a,-sse-unaligned-mem,+ssse3,-tagged-globals,-tbm,-tsxldtrk,-tuning-fast-imm-vector-shift,-uintr,-use-glm-div-sqrt-costs,-use-slm-arith-costs,-usermsr,+vaes,+vpclmulqdq,+vzeroupper,-waitpkg,+wbnoinvd,-widekl,+x87,-xop,+xsave,+xsavec,+xsaveopt,+xsaves" }
[nix-shell:~/src/zig/build-llvm18-release]$ ~/local/llvm18-assert/bin/clang -c reduced.ll -O3
clang: /home/andy/dev/llvm-project-18/llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:991: void {anonymous}::SelectionDAGLegalize::LegalizeOp(llvm::SDNode*): Assertion `(TLI.getTypeAction(*DAG.getContext(), Op.getValueType()) == TargetLowering::TypeLegal || Op.getOpcode() == ISD::TargetConstant || Op.getOpcode() == ISD::Register) &amp;&amp; "Unexpected illegal type!"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.      Program arguments: /home/andy/local/llvm18-assert/bin/clang -c reduced.ll -O3
1.      Code generation
2.      Running pass 'Function Pass Manager' on module 'reduced.ll'.
3.      Running pass 'X86 DAG-&gt;DAG Instruction Selection' on function '@"fmt.parse_float.decimal.Decimal(f16).leftShift"'
 #<!-- -->0 0x000000000387f4db llvm::sys::PrintStackTrace(llvm::raw_ostream&amp;, int) (/home/andy/local/llvm18-assert/bin/clang+0x387f4db)
 #<!-- -->1 0x000000000387c83b llvm::sys::RunSignalHandlers() (/home/andy/local/llvm18-assert/bin/clang+0x387c83b)
 #<!-- -->2 0x00000000037c1508 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
 #<!-- -->3 0x00007f2075454a70 __restore_rt (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x3da70)
 #<!-- -->4 0x00007f20754a3ddc __pthread_kill_implementation (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x8cddc)
 #<!-- -->5 0x00007f20754549c6 gsignal (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x3d9c6)
 #<!-- -->6 0x00007f207543d8fa abort (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x268fa)
 #<!-- -->7 0x00007f207543d819 _nl_load_domain.cold (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x26819)
 #<!-- -->8 0x00007f207544d3c6 (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x363c6)
 #<!-- -->9 0x00000000048a69fa (anonymous namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDNode*) LegalizeDAG.cpp:0:0
#<!-- -->10 0x00000000048b3100 llvm::SelectionDAG::Legalize() (/home/andy/local/llvm18-assert/bin/clang+0x48b3100)
#<!-- -->11 0x000000000499c826 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/home/andy/local/llvm18-assert/bin/clang+0x499c826)
#<!-- -->12 0x00000000049a06ac llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&amp;) (/home/andy/local/llvm18-assert/bin/clang+0x49a06ac)
#<!-- -->13 0x00000000049a2257 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&amp;) (.part.0) SelectionDAGISel.cpp:0:0
#<!-- -->14 0x0000000002409ff5 (anonymous namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&amp;) X86ISelDAGToDAG.cpp:0:0
#<!-- -->15 0x0000000002c30325 llvm::MachineFunctionPass::runOnFunction(llvm::Function&amp;) (.part.0) MachineFunctionPass.cpp:0:0
#<!-- -->16 0x0000000003213619 llvm::FPPassManager::runOnFunction(llvm::Function&amp;) (/home/andy/local/llvm18-assert/bin/clang+0x3213619)
#<!-- -->17 0x0000000003213751 llvm::FPPassManager::runOnModule(llvm::Module&amp;) (/home/andy/local/llvm18-assert/bin/clang+0x3213751)
#<!-- -->18 0x0000000003214057 llvm::legacy::PassManagerImpl::run(llvm::Module&amp;) (/home/andy/local/llvm18-assert/bin/clang+0x3214057)
#<!-- -->19 0x0000000003aedb33 clang::EmitBackendOutput(clang::DiagnosticsEngine&amp;, clang::HeaderSearchOptions const&amp;, clang::CodeGenOptions const&amp;, clang::TargetOptions const&amp;, clang::LangOptions const&amp;, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr&lt;llvm::vfs::FileSystem&gt;, std::unique_ptr&lt;llvm::raw_pwrite_stream, std::default_delete&lt;llvm::raw_pwrite_stream&gt;&gt;, clang::BackendConsumer*) (/home/andy/local/llvm18-assert/bin/clang+0x3aedb33)
#<!-- -->20 0x00000000040cd0fa clang::CodeGenAction::ExecuteAction() (/home/andy/local/llvm18-assert/bin/clang+0x40cd0fa)
#<!-- -->21 0x000000000434b2c9 clang::FrontendAction::Execute() (/home/andy/local/llvm18-assert/bin/clang+0x434b2c9)
#<!-- -->22 0x00000000042d0c02 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&amp;) (/home/andy/local/llvm18-assert/bin/clang+0x42d0c02)
#<!-- -->23 0x000000000441906f clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/home/andy/local/llvm18-assert/bin/clang+0x441906f)
#<!-- -->24 0x0000000000b7b6ca cc1_main(llvm::ArrayRef&lt;char const*&gt;, char const*, void*) (/home/andy/local/llvm18-assert/bin/clang+0xb7b6ca)
#<!-- -->25 0x0000000000b736a7 ExecuteCC1Tool(llvm::SmallVectorImpl&lt;char const*&gt;&amp;, llvm::ToolContext const&amp;) driver.cpp:0:0
#<!-- -->26 0x000000000410e509 void llvm::function_ref&lt;void ()&gt;::callback_fn&lt;clang::driver::CC1Command::Execute(llvm::ArrayRef&lt;std::optional&lt;llvm::StringRef&gt;&gt;, std::__cxx11::basic_string&lt;char, std::char_traits&lt;char&gt;, std::allocator&lt;char&gt;&gt;*, bool*) const::'lambda'()&gt;(long) Job.cpp:0:0
#<!-- -->27 0x00000000037c1962 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref&lt;void ()&gt;) (/home/andy/local/llvm18-assert/bin/clang+0x37c1962)
#<!-- -->28 0x000000000410fbf4 clang::driver::CC1Command::Execute(llvm::ArrayRef&lt;std::optional&lt;llvm::StringRef&gt;&gt;, std::__cxx11::basic_string&lt;char, std::char_traits&lt;char&gt;, std::allocator&lt;char&gt;&gt;*, bool*) const (.part.0) Job.cpp:0:0
#<!-- -->29 0x00000000040d6ae5 clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&amp;, clang::driver::Command const*&amp;, bool) const (/home/andy/local/llvm18-assert/bin/clang+0x40d6ae5)
#<!-- -->30 0x00000000040d75dd clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&amp;, llvm::SmallVectorImpl&lt;std::pair&lt;int, clang::driver::Command const*&gt;&gt;&amp;, bool) const (/home/andy/local/llvm18-assert/bin/clang+0x40d75dd)
#<!-- -->31 0x00000000040e1bb4 clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&amp;, llvm::SmallVectorImpl&lt;std::pair&lt;int, clang::driver::Command const*&gt;&gt;&amp;) (/home/andy/local/llvm18-assert/bin/clang+0x40e1bb4)
#<!-- -->32 0x0000000000b78d69 clang_main(int, char**, llvm::ToolContext const&amp;) (/home/andy/local/llvm18-assert/bin/clang+0xb78d69)
#<!-- -->33 0x0000000000a6feb3 main (/home/andy/local/llvm18-assert/bin/clang+0xa6feb3)
#<!-- -->34 0x00007f207543efce __libc_start_call_main (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x27fce)
#<!-- -->35 0x00007f207543f089 __libc_start_main@<!-- -->GLIBC_2.2.5 (/nix/store/anlf335xlh41yjhm114swi87406mq5pw-glibc-2.38-44/lib/libc.so.6+0x28089)
#<!-- -->36 0x0000000000b72315 _start (/home/andy/local/llvm18-assert/bin/clang+0xb72315)
clang: error: clang frontend command failed with exit code 134 (use -v to see invocation)
clang version 18.1.5 (https://github.com/llvm/llvm-project 78b99c73ee4b96fe9ce0e294d4632326afb2db42)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/andy/local/llvm18-assert/bin
clang: note: diagnostic msg: Error generating preprocessed source(s) - no preprocessable inputs.

@topperc
Copy link
Collaborator

topperc commented Apr 28, 2024

It looks like X86Subtarget::canExtendTo512BW() returns true when X86Subtarget::useAVX512Regs() returns false. That's not how it used to work. If X86Subtarget::canExtendTo512BW() returned true, X86Subtarget::useAVX512Regs() also needed to return true.

The change seems to be that X86Subtarget::useAVX512Regs() now checks X86Subtarget::hasEVEX512() which is false in this test. X86Subtarget::canExtendTo512BW() does not check X86Subtarget::hasEVEX512().

CC: @phoebewang

@phoebewang
Copy link
Contributor

It looks like X86Subtarget::canExtendTo512BW() returns true when X86Subtarget::useAVX512Regs() returns false. That's not how it used to work. If X86Subtarget::canExtendTo512BW() returned true, X86Subtarget::useAVX512Regs() also needed to return true.

The change seems to be that X86Subtarget::useAVX512Regs() now checks X86Subtarget::hasEVEX512() which is false in this test. X86Subtarget::canExtendTo512BW() does not check X86Subtarget::hasEVEX512().

CC: @phoebewang

Thanks @topperc. This is a bug, should be solved by #90390

@EugeneZelenko EugeneZelenko removed the llvm:SelectionDAG SelectionDAGISel as well label Apr 28, 2024
@topperc
Copy link
Collaborator

topperc commented Apr 28, 2024

@phoebewang does the Zig frontend, or other non-clang frontends, need to set "+evex512" in order to get 512-bit instructions now?

@andrewrk
Copy link
Member Author

andrewrk commented Apr 28, 2024

Do I understand correctly that it this was an odd combination of CPU target features, and that it was expected that evex512 is likely supported on my CPU (AMD Ryzen 9 7950X 16-Core Processor)?

If so, I'll additionally address this downstream with ziglang/zig#19793

@phoebewang
Copy link
Contributor

@phoebewang does the Zig frontend, or other non-clang frontends, need to set "+evex512" in order to get 512-bit instructions now?

Clang FE now set "+evex512" for all -mavx512xxx options. Backend tries to provide the backward compatibility as much as possible. So if non-clang frontends don't specify a target or specify a AVX512 target, it still can get 512-bit instructions. The problem here is the frontend explicitly set a "-evex512".

@phoebewang
Copy link
Contributor

phoebewang commented Apr 29, 2024

Do I understand correctly that it this was an odd combination of CPU target features, and that it was expected that evex512 is likely supported on my CPU (AMD Ryzen 9 7950X 16-Core Processor)?

If so, I'll additionally address this upstream with ziglang/zig#19793

Yes. There are two problems here:

  • The frontend should set "+evex512" instead of "-evex512" for a 512-bit target;
  • If the frontend cannot determine it, it should set neither and pass the "target-cpu" to let backend handle it;

@topperc
Copy link
Collaborator

topperc commented Apr 29, 2024

Do I understand correctly that it this was an odd combination of CPU target features, and that it was expected that evex512 is likely supported on my CPU (AMD Ryzen 9 7950X 16-Core Processor)?
If so, I'll additionally address this upstream with ziglang/zig#19793

Yes. There are two problems here:

  • The frontend should set "+evex512" instead of "-evex512" for a 512-bit target;
  • If the frontend cannot determine it, it should set neither and pass the "target-cpu" to let backend handle it;

So we introduced a backwards incompatible change in llvm-18?

Should getHostCPUFeatures also set "+evex512" for -march=native? It probably mostly works because -march=native will find a CPU name that has the feature.

@phoebewang
Copy link
Contributor

Do I understand correctly that it this was an odd combination of CPU target features, and that it was expected that evex512 is likely supported on my CPU (AMD Ryzen 9 7950X 16-Core Processor)?
If so, I'll additionally address this upstream with ziglang/zig#19793

Yes. There are two problems here:

  • The frontend should set "+evex512" instead of "-evex512" for a 512-bit target;
  • If the frontend cannot determine it, it should set neither and pass the "target-cpu" to let backend handle it;

So we introduced a backwards incompatible change in llvm-18?

Should getHostCPUFeatures also set "+evex512" for -march=native? It probably mostly works because -march=native will find a CPU name that has the feature.

We have set "+evex512" for -march=native, see https://godbolt.org/z/Phaer44vb
There's only one case has incompatible behavior, i.e., the frontend passes both a none AVX512 target and a few AVX512 features without an explict "[+-]evex512". I don't think it is a valid scenario since we have AVX10-256 and AVX10-512 now.

@topperc
Copy link
Collaborator

topperc commented Apr 29, 2024

Do I understand correctly that it this was an odd combination of CPU target features, and that it was expected that evex512 is likely supported on my CPU (AMD Ryzen 9 7950X 16-Core Processor)?
If so, I'll additionally address this upstream with ziglang/zig#19793

Yes. There are two problems here:

  • The frontend should set "+evex512" instead of "-evex512" for a 512-bit target;
  • If the frontend cannot determine it, it should set neither and pass the "target-cpu" to let backend handle it;

So we introduced a backwards incompatible change in llvm-18?
Should getHostCPUFeatures also set "+evex512" for -march=native? It probably mostly works because -march=native will find a CPU name that has the feature.

We have set "+evex512" for -march=native, see https://godbolt.org/z/Phaer44vb

clang sets "+evex512" for -march=native but its not part of getHostCPUFeatures. It's part of clang's X86.cpp so any frontend that isn't clang that uses getHostCPUFeatures needs to replicate clang's code.

There's only one case has incompatible behavior, i.e., the frontend passes both a none AVX512 target and a few AVX512 features without an explict "[+-]evex512". I don't think it is a valid scenario since we have AVX10-256 and AVX10-512 now.

The need for explicit "+evex512" is not mentioned in the clang-18 release notes. How are non-clang frontends supposed to know about this new requirement?

@andrewrk
Copy link
Member Author

How are non-clang frontends supposed to know about this new requirement?

In this case specifically, the znver4 CPU model has the evex512 feature listed, so fixing the frontend's CPU model detection will also make it enable this CPU feature.

@topperc
Copy link
Collaborator

topperc commented Apr 29, 2024

How are non-clang frontends supposed to know about this new requirement?

In this case specifically, the znver4 CPU model has the evex512 feature listed, so fixing the frontend's CPU model detection will also make it enable this CPU feature.

Yes as long as both getHostCPUName and getHostCPUFeatures are both used, and getHostCPUName is able to identify it as a CPU LLVM knows about, then it will work correctly. So LLVM-18 could be broken on a future CPU that hasn't been released yet. The code in getHostCPUName has fallbacks for unknown family and model in CPUID that will try to pick the most modern CPU it knows about. So it will likely work, but it's not a guarantee.

The other scenario is if there is a CPU that implements avx512 and cpuid that is not from AMD or Intel. In that case, LLVM probably doesn't pick a cpu name other than "generic" for getHostCPUName.

@phoebewang
Copy link
Contributor

phoebewang commented Apr 29, 2024

How are non-clang frontends supposed to know about this new requirement?

In this case specifically, the znver4 CPU model has the evex512 feature listed, so fixing the frontend's CPU model detection will also make it enable this CPU feature.

Yes as long as both getHostCPUName and getHostCPUFeatures are both used, and getHostCPUName is able to identify it as a CPU LLVM knows about, then it will work correctly. So LLVM-18 could be broken on a future CPU that hasn't been released yet. The code in getHostCPUName has fallbacks for unknown family and model in CPUID that will try to pick the most modern CPU it knows about. So it will likely work, but it's not a guarantee.

Future CPU needs to specify FeatureEVEX512 explicitly like other AVX512 targets, e.g., https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/X86/X86.td#L974 It doesn't look a big problem.

The other scenario is if there is a CPU that implements avx512 and cpuid that is not from AMD or Intel. In that case, LLVM probably doesn't pick a cpu name other than "generic" for getHostCPUName.

I think other CPU should follow the same rule here.

@topperc
Copy link
Collaborator

topperc commented Apr 29, 2024

How are non-clang frontends supposed to know about this new requirement?

In this case specifically, the znver4 CPU model has the evex512 feature listed, so fixing the frontend's CPU model detection will also make it enable this CPU feature.

Yes as long as both getHostCPUName and getHostCPUFeatures are both used, and getHostCPUName is able to identify it as a CPU LLVM knows about, then it will work correctly. So LLVM-18 could be broken on a future CPU that hasn't been released yet. The code in getHostCPUName has fallbacks for unknown family and model in CPUID that will try to pick the most modern CPU it knows about. So it will likely work, but it's not a guarantee.

Future CPU needs to specify FeatureEVEX512 explicitly like other AVX512 targets, e.g., https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/X86/X86.td#L974 It doesn't look a big problem.

I'm talking about a currently unknown future CPU a year or two or more from now using the llvm 18.1 release binaries that exist today.

I think other CPU should follow the same rule here.

Centaur Technologies has made AVX512 CPUs that LLVM does not know about.

@phoebewang
Copy link
Contributor

How are non-clang frontends supposed to know about this new requirement?

In this case specifically, the znver4 CPU model has the evex512 feature listed, so fixing the frontend's CPU model detection will also make it enable this CPU feature.

Yes as long as both getHostCPUName and getHostCPUFeatures are both used, and getHostCPUName is able to identify it as a CPU LLVM knows about, then it will work correctly. So LLVM-18 could be broken on a future CPU that hasn't been released yet. The code in getHostCPUName has fallbacks for unknown family and model in CPUID that will try to pick the most modern CPU it knows about. So it will likely work, but it's not a guarantee.

Future CPU needs to specify FeatureEVEX512 explicitly like other AVX512 targets, e.g., https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/X86/X86.td#L974 It doesn't look a big problem.

I'm talking about a currently unknown future CPU a year or two or more from now using the llvm 18.1 release binaries that exist today.

It still looks weird to me. If the CPU is not listed on llvm 18.1, user should avoid to pass it to LLVM backend. If user wants to emulate it with existing CPUs, they can choose a base AVX512 target, e.g., skylake-avx512 or just use a group of discrete -mavx512xxx features without specify a target.

I think other CPU should follow the same rule here.

Centaur Technologies has made AVX512 CPUs that LLVM does not know about.

Good to know! But still, I think they need to define their target in X86.td. Or, if they want to emulate it, they can use the way above.

Anyway, I agree with you it's always better to mention it in release note.

@topperc
Copy link
Collaborator

topperc commented Apr 29, 2024

How are non-clang frontends supposed to know about this new requirement?

In this case specifically, the znver4 CPU model has the evex512 feature listed, so fixing the frontend's CPU model detection will also make it enable this CPU feature.

Yes as long as both getHostCPUName and getHostCPUFeatures are both used, and getHostCPUName is able to identify it as a CPU LLVM knows about, then it will work correctly. So LLVM-18 could be broken on a future CPU that hasn't been released yet. The code in getHostCPUName has fallbacks for unknown family and model in CPUID that will try to pick the most modern CPU it knows about. So it will likely work, but it's not a guarantee.

Future CPU needs to specify FeatureEVEX512 explicitly like other AVX512 targets, e.g., https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/X86/X86.td#L974 It doesn't look a big problem.

I'm talking about a currently unknown future CPU a year or two or more from now using the llvm 18.1 release binaries that exist today.

It still looks weird to me. If the CPU is not listed on llvm 18.1, user should avoid to pass it to LLVM backend. If user wants to emulate it with existing CPUs, they can choose a base AVX512 target, e.g., skylake-avx512 or just use a group of discrete -mavx512xxx features without specify a target.

I'm not talking about the user passing a CPU. I'm talking about the user using the equivalent of -march=native in some other frontend that isn't clang. If that frontend uses getHostCPUName, it might not return an older AVX512 CPU name if real CPU is one LLVM doesn't yet know about.

Historically a frontend could just pass the results from getHostCPUName/getHostCPUFeatures directly to LLVM. Now a frontend needs to manually add +evex512 in some cases in order to get 512-bit codegen.

Anyway I guess the damage is already done. The least we can do is update the release notes.

@phoebewang
Copy link
Contributor

I'm not talking about the user passing a CPU. I'm talking about the user using the equivalent of -march=native in some other frontend that isn't clang. If that frontend uses getHostCPUName, it might not return an older AVX512 CPU name if real CPU is one LLVM doesn't yet know about.

Thanks @topperc! I got the point now.

Historically a frontend could just pass the results from getHostCPUName/getHostCPUFeatures directly to LLVM. Now a frontend needs to manually add +evex512 in some cases in order to get 512-bit codegen.

Then I agree adding "+evex512" to getHostCPUName/getHostCPUFeatures is a good idea. I created a #90479, PTAL. Though currently it still works as long as the fronend set the default CPU to pentium4/x86-64, see https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/X86/X86Subtarget.cpp#L263-L265

Anyway I guess the damage is already done. The least we can do is update the release notes.

Maybe #90479 is better than a doc warning :)

tstellar pushed a commit to llvmbot/llvm-project that referenced this issue Apr 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backend:X86 bug Indicates an unexpected problem or unintended behavior regression
Projects
Development

Successfully merging a pull request may close this issue.

5 participants