Bug 92709 - "LLVM triggered Diagnostic Handler: unsupported call to function ldexpf in main" when starting race in stuntrally
Summary: "LLVM triggered Diagnostic Handler: unsupported call to function ldexpf in ma...
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
URL:
Whiteboard:
Keywords:
: 92913 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-10-28 14:28 UTC by Christoph Haag
Modified: 2015-12-04 01:59 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:

Attachments
Patch for LLVM (40.71 KB, patch)
2015-11-04 10:54 UTC, Nicolai Hähnle 		Details | Splinter Review
View All

Description Christoph Haag 2015-10-28 14:28:57 UTC 
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
Comment 1 Michel Dänzer 2015-10-29 05:56:26 UTC 
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.
Comment 2 Matt Arsenault 2015-10-31 08:43:30 UTC 
(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.
Comment 3 Michel Dänzer 2015-11-02 10:03:32 UTC 
(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.
Comment 4 Nicolai Hähnle 2015-11-02 13:23:42 UTC 
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?
Comment 5 Matt Arsenault 2015-11-02 17:33:14 UTC 
(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.
Comment 6 Michel Dänzer 2015-11-04 02:58:26 UTC 
(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"...
Comment 7 Matt Arsenault 2015-11-04 03:06:30 UTC 
(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.
Comment 8 Nicolai Hähnle 2015-11-04 10:54:47 UTC 
Created attachment 119396 [details] [review]
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
Comment 9 Michel Dänzer 2015-11-19 02:27:29 UTC 
*** Bug 92913 has been marked as a duplicate of this bug. ***
Comment 10 Michel Dänzer 2015-11-24 09:12:48 UTC 
Module: Mesa
Branch: master
Commit: d09463193608009fa42e046b1fc144435d3533f6
URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=d09463193608009fa42e046b1fc144435d3533f6

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
Comment 11 higuita 2015-12-04 01:52:17 UTC 
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_iterator<llvm::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)
Comment 12 Michel Dänzer 2015-12-04 01:59:06 UTC 
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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.