[llvm-dev] Difference between -mattr=+soft-float and -float-abi=soft

Moritz Angermann via llvm-dev llvm-dev at lists.llvm.org
Tue Sep 26 03:05:53 PDT 2017

Hi Tim,

Ohh, I completely forgot to attach the source. Running this with:

$ llc -O2 -mcpu=generic HeapStackCheck.ll -mattr=+soft-float -o HeapStackCheck.s

results in

0  llc                      0x000000010fea65e6 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 37
1  llc                      0x000000010fea5b3a llvm::sys::RunSignalHandlers() + 83
2  llc                      0x000000010fea69d6 SignalHandler(int) + 191
3  libsystem_platform.dylib 0x00007fffb45acb3a _sigtramp + 26
4  libsystem_platform.dylib 000000000000000000 _sigtramp + 1269118176
5  llc                      0x000000010fe15779 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 1029
6  llc                      0x000000010fe14ac7 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 1521
7  llc                      0x000000010f1b56d4 (anonymous namespace)::ARMDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 20
8  llc                      0x000000010f9b7914 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 114
9  llc                      0x000000010fb357e6 llvm::FPPassManager::runOnFunction(llvm::Function&) + 294
10 llc                      0x000000010fb359a5 llvm::FPPassManager::runOnModule(llvm::Module&) + 49
11 llc                      0x000000010fb35ce1 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 587
12 llc                      0x000000010ef4b962 compileModule(char**, llvm::LLVMContext&) + 6646
13 llc                      0x000000010ef49bae main + 891
14 libdyld.dylib            0x00007fffb439d235 start + 1
15 libdyld.dylib            0x0000000000000007 start + 1271279059
Stack dump:
0.	Program arguments: llc -O2 -mcpu=generic HeapStackCheck.ll -mattr=+soft-float -o HeapStackCheck.s 
1.	Running pass 'Function Pass Manager' on module 'rts/HeapStackCheck.ll'.
2.	Running pass 'ARM Instruction Selection' on function '@stg_gc_f1'
[1]    85435 segmentation fault  llc -O2 -mcpu=generic HeapStackCheck.ll -mattr=+soft-float -o

$ llc -O2 -mcpu=generic rts/HeapStackCheck.ll -float-abi=soft -o rts/HeapStackCheck.s

will succeed however.

Given your explanation, this might be due to the fact how the `ghccc` tries to pass
everything is registers. And which is why this falls apart when float registers are

Maybe the lesson here is that a few more adjustments in GHC are needed to not emit
code using float registers if we use soft float.

I still don’t understand why `-float-abi=soft` would compile then. Maybe it simply has
no effect with `ghccc` then?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: HeapStackCheck.ll
Type: application/octet-stream
Size: 92224 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170926/dc09fb2b/attachment-0001.obj>
-------------- next part --------------

> On Sep 26, 2017, at 5:22 PM, Tim Northover <t.p.northover at gmail.com> wrote:
> Hi Moritz,
> On 26 September 2017 at 09:09, Moritz Angermann via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> I’ve run into a case where `llc -mattr=+soft-float` for
>> "armv7-unknown-linux-androideabi” segfaults, while
>> `llc -float-abi=soft` does not.  Similarly if the
>> "target-features"="+soft-float” metadata is embedded,
>> llc segfaults.
> The float-abi option specifies which registers should be used to pass
> floating-point values during function calls. The +soft-float option
> tells Clang that no floating-point instructions or registers should be
> used, so LLVM will make calls to software routines instead of using
> the FPU.
> In theory they should both be reasonably well tested so a segfault is
> slightly surprising. The only idea I can come up with (without source)
> is that you've ended up in an inconsistent state: maybe LLVM thinks it
> needs to use VFP registers (float-abi=hard) but can't use VFP
> instructions to get data there (+soft-float). That wouldn't end well.
> Cheers.
> Tim.

More information about the llvm-dev mailing list