Bug 92709

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.

(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.

(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.

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?

(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.

(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"...

(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.

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

*** Bug 92913 has been marked as a duplicate of this bug. ***

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

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)

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.