[Bug 92709] "LLVM triggered Diagnostic Handler: unsupported call to function ldexpf in main" when starting race in stuntrally
https://bugs.freedesktop.org/show_bug.cgi?id=92709
Bug ID: 92709 Summary: "LLVM triggered Diagnostic Handler: unsupported call to function ldexpf in main" when starting race in stuntrally Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: haagch@frickel.club QA Contact: dri-devel@lists.freedesktop.org
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Wimbledon XT [Radeon HD 7970M] (rev ff)
llvm-svn 251500 (but happened at least since 251005) mesa git stuntrally 2.6
Here is a trace (167 mb compressed): http://haagch.frickel.club/files/stuntrally.trace.xz It replays fine on intel, but produces said exception on radeonsi:
[...] LLVM triggered Diagnostic Handler: unsupported call to function ldexpf in main apitrace: warning: caught signal 11 601245: error: caught an unhandled exception glretrace+0x23c99c /usr/lib/libpthread.so.0+0x10d5f /usr/lib/libLLVM.so.3.8+0xa96976 /usr/lib/libLLVM.so.3.8: _ZNK4llvm14TargetLowering11LowerCallToERNS0_16CallLoweringInfoE+0x1406 /usr/lib/libLLVM.so.3.8: _ZN4llvm19SelectionDAGBuilder14lowerInvokableERNS_14TargetLowering16CallLoweringInfoEPKNS_10BasicBlockE+0x38b /usr/lib/libLLVM.so.3.8: _ZN4llvm19SelectionDAGBuilder11LowerCallToENS_17ImmutableCallSiteENS_7SDValueEbPKNS_10BasicBlockE+0x62e /usr/lib/libLLVM.so.3.8: _ZN4llvm19SelectionDAGBuilder9visitCallERKNS_8CallInstE+0x9f /usr/lib/libLLVM.so.3.8: _ZN4llvm19SelectionDAGBuilder5visitERKNS_11InstructionE+0x33 /usr/lib/libLLVM.so.3.8: _ZN4llvm16SelectionDAGISel16SelectBasicBlockENS_14ilist_iteratorIKNS_11InstructionEEES4_Rb+0x37 /usr/lib/libLLVM.so.3.8: _ZN4llvm16SelectionDAGISel20SelectAllBasicBlocksERKNS_8FunctionE+0x38f /usr/lib/libLLVM.so.3.8: _ZN4llvm16SelectionDAGISel20runOnMachineFunctionERNS_15MachineFunctionE+0x471 /usr/lib/libLLVM.so.3.8: _ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE+0x289 /usr/lib/libLLVM.so.3.8: _ZN4llvm13FPPassManager11runOnModuleERNS_6ModuleE+0x2a /usr/lib/libLLVM.so.3.8: _ZN4llvm6legacy15PassManagerImpl3runERNS_6ModuleE+0x300 /usr/lib/libLLVM.so.3.8+0x1205e7e /usr/lib/libLLVM.so.3.8: LLVMTargetMachineEmitToMemoryBuffer+0xa8 /usr/lib/xorg/modules/dri/radeonsi_dri.so+0x591aaf /usr/lib/xorg/modules/dri/radeonsi_dri.so+0x50f0ea /usr/lib/xorg/modules/dri/radeonsi_dri.so+0x50fe37 /usr/lib/xorg/modules/dri/radeonsi_dri.so+0x51a894 /usr/lib/xorg/modules/dri/radeonsi_dri.so+0x51b405 /usr/lib/xorg/modules/dri/radeonsi_dri.so+0x517ade /usr/lib/xorg/modules/dri/radeonsi_dri.so+0x3a4e16 /usr/lib/xorg/modules/dri/radeonsi_dri.so+0x1fe042 /usr/lib/xorg/modules/dri/radeonsi_dri.so+0x1cd399 glretrace+0xd51c9 glretrace+0xbd1c glretrace+0xc37b glretrace+0x7b04 /usr/lib/libc.so.6: __libc_start_main+0xef glretrace: _start+0x28
https://bugs.freedesktop.org/show_bug.cgi?id=92709
Michel Dänzer michel@daenzer.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |arsenm2@gmail.com, | |tstellar@gmail.com
--- Comment #1 from Michel Dänzer michel@daenzer.net --- This happens since Mesa commit d72a26ec ("radeonsi: don't emit AMDGPU intrinsics for EX2, ROUND, TRUNC") because the LLVM function LibCallSimplifier::optimizeExp2() replaces the llvm.exp2.f32 call (which could be handled by the AMDGPU backend AFAICT) with an ldexpf one.
https://bugs.freedesktop.org/show_bug.cgi?id=92709
--- Comment #2 from Matt Arsenault arsenm2@gmail.com --- (In reply to Michel Dänzer from comment #1)
This happens since Mesa commit d72a26ec ("radeonsi: don't emit AMDGPU intrinsics for EX2, ROUND, TRUNC") because the LLVM function LibCallSimplifier::optimizeExp2() replaces the llvm.exp2.f32 call (which could be handled by the AMDGPU backend AFAICT) with an ldexpf one.
This is one of those annoying cases where ldexp doesn't have an equivalent generic ISD node. We should probably add one and use it for the libcall and handle it like most of the other math LibFuncs.
https://bugs.freedesktop.org/show_bug.cgi?id=92709
Michel Dänzer michel@daenzer.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nhaehnle@gmail.com
--- Comment #3 from Michel Dänzer michel@daenzer.net --- (In reply to Matt Arsenault from comment #2)
This is one of those annoying cases where ldexp doesn't have an equivalent generic ISD node. We should probably add one and use it for the libcall and handle it like most of the other math LibFuncs.
Do you think you or someone else (Nicolai?) can look into this soon? Otherwise, we probably need to to stop using this from Mesa again for now.
https://bugs.freedesktop.org/show_bug.cgi?id=92709
--- Comment #4 from Nicolai Hähnle nhaehnle@gmail.com --- Sure, I can look into that.
Matt, just to clarify: You mean adding a generic ISD::FLDEXP to ISDOpcodes.h, together with assorted tests and changes in the generic CodeGen infrastructure, right?
https://bugs.freedesktop.org/show_bug.cgi?id=92709
--- Comment #5 from Matt Arsenault arsenm2@gmail.com --- (In reply to Nicolai Hähnle from comment #4)
Sure, I can look into that.
Matt, just to clarify: You mean adding a generic ISD::FLDEXP to ISDOpcodes.h, together with assorted tests and changes in the generic CodeGen infrastructure, right?
Yes. This should be pretty trivial to do.
Alternatively, it would probably be better to have an ldexp llvm intrinsic (which would also have the corresponding ISD::FLDEXP). It seems bizarre that an llvm intrinsic would ever be changed to something involving a library call.
https://bugs.freedesktop.org/show_bug.cgi?id=92709
--- Comment #6 from Michel Dänzer michel@daenzer.net --- (In reply to Matt Arsenault from comment #5)
It seems bizarre that an llvm intrinsic would ever be changed to something involving a library call.
I think the exp2 -> ldexpf transform is rather questionable for us anyway, since we have a native exp2 instruction, isn't it? Maybe we just don't want to use the LibCallSimplifier pass? The comment at the top of SimplifyLibCalls.cpp kind of sounds like "this is not the pass you're looking for"...
https://bugs.freedesktop.org/show_bug.cgi?id=92709
--- Comment #7 from Matt Arsenault arsenm2@gmail.com --- (In reply to Michel Dänzer from comment #6)
(In reply to Matt Arsenault from comment #5)
It seems bizarre that an llvm intrinsic would ever be changed to something involving a library call.
I think the exp2 -> ldexpf transform is rather questionable for us anyway, since we have a native exp2 instruction, isn't it? Maybe we just don't want to use the LibCallSimplifier pass? The comment at the top of SimplifyLibCalls.cpp kind of sounds like "this is not the pass you're looking for"...
We do want this. ldexp is a full rate instruction, and exp2 is a quarter rate instruction.
https://bugs.freedesktop.org/show_bug.cgi?id=92709
--- Comment #8 from Nicolai Hähnle nhaehnle@gmail.com --- Created attachment 119396 --> https://bugs.freedesktop.org/attachment.cgi?id=119396&action=edit Patch for LLVM
Here's a first cut at a patch that adds an llvm.ldexp.* intrinsic, so that LibCallSimplifier generates that instead of the call to ldexpf, and codegen is able to select the right instruction. With this change, Christoph's trace runs to completion without errors.
See also http://reviews.llvm.org/D14327
https://bugs.freedesktop.org/show_bug.cgi?id=92709
Michel Dänzer michel@daenzer.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kai@dev.carbon-project.org
--- Comment #9 from Michel Dänzer michel@daenzer.net --- *** Bug 92913 has been marked as a duplicate of this bug. ***
https://bugs.freedesktop.org/show_bug.cgi?id=92709
Michel Dänzer michel@daenzer.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #10 from Michel Dänzer michel@daenzer.net --- Module: Mesa Branch: master Commit: d09463193608009fa42e046b1fc144435d3533f6 URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=d09463193608009fa42e046b1fc...
Author: Michel Dänzer michel.daenzer@amd.com Date: Thu Nov 19 11:30:21 2015 +0900
radeon/llvm: Use llvm.AMDIL.exp intrinsic again for now
https://bugs.freedesktop.org/show_bug.cgi?id=92709
higuita@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |---
--- Comment #11 from higuita@gmx.net --- i'm getting this error using mesa 11.1.0-rc2 and llvm 3.7.0 when starting WarThunder:
16:07:32 /mnt/SteamOS/SteamApps/common/War Thunder/$ ./aces [S_API FAIL] SteamAPI_Init() failed; no appID found. Either launch the game from Steam, or put the file steam_appid.txt containing the correct appID in your game folder. LLVM triggered Diagnostic Handler: unsupported call to function ldexpf in main Segmentation fault (core dumped)
This after building mesa with debug enabled, as before enabling it, i didn't see anything.
From this bug, this was fixed and checking the mesa source, it is using
"llvm.AMDIL.exp"... yet i get the same error message.Maybe this patch was not enough?
Here is the gdb backtrace:
Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f0ce26c287e in __strstr_sse2 () from /lib64/libc.so.6 [Current thread is 1 (Thread 0x7f0ce427f200 (LWP 13990))] (gdb) bt #0 0x00007f0ce26c287e in __strstr_sse2 () from /lib64/libc.so.6 #1 0x0000000000949934 in ?? () #2 0x00000000007c6235 in ?? () #3 0x0000000001895647 in ?? () #4 0x0000000001dae23c in ?? () #5 <signal handler called> #6 0x00007f0cd601977e in ?? () from /usr/lib64/../lib64/libLLVM.so.3.7 #7 0x00007f0cd6043095 in llvm::TargetLowering::LowerCallTo(llvm::TargetLowering::CallLoweringInfo&) const () from /usr/lib64/../lib64/libLLVM.so.3.7 #8 0x00007f0cd60440ec in llvm::SelectionDAGBuilder::lowerInvokable(llvm::TargetLowering::CallLoweringInfo&, llvm::MachineBasicBlock*) () from /usr/lib64/../lib64/libLLVM.so.3.7 #9 0x00007f0cd6032cd1 in llvm::SelectionDAGBuilder::LowerCallTo(llvm::ImmutableCallSite, llvm::SDValue, bool, llvm::MachineBasicBlock*) () from /usr/lib64/../lib64/libLLVM.so.3.7 #10 0x00007f0cd6024fc0 in llvm::SelectionDAGBuilder::visitCall(llvm::CallInst const&) () from /usr/lib64/../lib64/libLLVM.so.3.7 #11 0x00007f0cd601c972 in llvm::SelectionDAGBuilder::visit(llvm::Instruction const&) () from /usr/lib64/../lib64/libLLVM.so.3.7 #12 0x00007f0cd605aa68 in llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iteratorllvm::Instruction const, llvm::ilist_iterator<llvm::Instruction const>, bool&) () from /usr/lib64/../lib64/libLLVM.so.3.7 #13 0x00007f0cd605a9a2 in llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) () from /usr/lib64/../lib64/libLLVM.so.3.7 #14 0x00007f0cd60594f4 in llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) () from /usr/lib64/../lib64/libLLVM.so.3.7 #15 0x00007f0cd5e15173 in llvm::MachineFunctionPass::runOnFunction(llvm::Function&) () from /usr/lib64/../lib64/libLLVM.so.3.7 #16 0x00007f0cd5d26a0b in llvm::FPPassManager::runOnFunction(llvm::Function&) () from /usr/lib64/../lib64/libLLVM.so.3.7 #17 0x00007f0cd5d26beb in llvm::FPPassManager::runOnModule(llvm::Module&) () from /usr/lib64/../lib64/libLLVM.so.3.7 #18 0x00007f0cd5d26ffb in llvm::legacy::PassManagerImpl::run(llvm::Module&) () from /usr/lib64/../lib64/libLLVM.so.3.7 #19 0x00007f0cd66048d2 in ?? () from /usr/lib64/../lib64/libLLVM.so.3.7 #20 0x00007f0cd66049a8 in LLVMTargetMachineEmitToMemoryBuffer () from /usr/lib64/../lib64/libLLVM.so.3.7 #21 0x00007f0cde424cbc in ?? () from /usr/lib64/xorg/modules/dri/radeonsi_dri.so #22 0x00007f0cde3997ba in ?? () from /usr/lib64/xorg/modules/dri/radeonsi_dri.so #23 0x00007f0cde39a484 in ?? () from /usr/lib64/xorg/modules/dri/radeonsi_dri.so #24 0x00007f0cde3a5c05 in ?? () from /usr/lib64/xorg/modules/dri/radeonsi_dri.so #25 0x00007f0cde3a6e9c in ?? () from /usr/lib64/xorg/modules/dri/radeonsi_dri.so #26 0x00007f0cde3a2212 in ?? () from /usr/lib64/xorg/modules/dri/radeonsi_dri.so #27 0x00007f0cde2912f1 in ?? () from /usr/lib64/xorg/modules/dri/radeonsi_dri.so #28 0x00007f0cde219656 in ?? () from /usr/lib64/xorg/modules/dri/radeonsi_dri.so #29 0x00007f0cde0d7d96 in ?? () from /usr/lib64/xorg/modules/dri/radeonsi_dri.so #30 0x00007f0cde0a1324 in ?? () from /usr/lib64/xorg/modules/dri/radeonsi_dri.so #31 0x00007f0cde0a1544 in ?? () from /usr/lib64/xorg/modules/dri/radeonsi_dri.so #32 0x00000000018b6e31 in ?? () #33 0x0000000001ee8f8a in ?? () #34 0x0000000001265a67 in ?? () #35 0x0000000001265f72 in ?? () #36 0x00000000012662df in ?? () #37 0x000000000126a765 in ?? () #38 0x0000000000898628 in ?? () #39 0x00000000008b7462 in ?? () #40 0x0000000000800b72 in ?? () #41 0x0000000000efc730 in ?? () #42 0x00000000007d2615 in ?? () #43 0x00000000004152ee in ?? () #44 0x00007f0ce2654870 in __libc_start_main () from /lib64/libc.so.6 #45 0x0000000000435751 in ?? () #46 0x00007ffff1bc9748 in ?? () #47 0x000000000000001c in ?? () #48 0x0000000000000001 in ?? () #49 0x00007ffff1bcafe9 in ?? () #50 0x0000000000000000 in ?? ()
i have the core dump and the apitrace (but replay the trace don't generate any problem other than the wrong window output)
https://bugs.freedesktop.org/show_bug.cgi?id=92709
Michel Dänzer michel@daenzer.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED
--- Comment #12 from Michel Dänzer michel@daenzer.net --- That's because the fix isn't in 11.1.0-rc2. I've now nominated the fix for backporting to the 11.1 branch, so it should be in the next release candidate.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org