llvm dev - Jun 2015 - [LLVMdev] How to pick default floating point ABI?

On 06/12/2015 07:12 PM, Daniel Sanders wrote:
>
> Hi,
>
> I'm afraid targeting a 64-bit CPU and the O32 ABI is completely broken 
> at the moment, it's one of the very long-standing issues I'm
working
> towards. The main problem is that a lot of the internals of the Mips 
> LLVM backend derive their behaviour from the target CPU rather than 
> the target ABI. In theory, the combination of mips3 and O32 is valid 
> and should generate code pretty much the same way as mips2 and O32 
> does. In the current implementation, the fact that mips3 has 64-bit 
> GPR's tells a lot of the code generator to use 64-bit instructions and 
> selects other behaviour that is correct for the N32/N64 ABI's but not 
> for O32. For this (and many other) reasons, there's an assertion that 
> O32 is not used on a 64-bit CPU.
>
> Any patches that make progress on this will be warmly welcomed. In the 
> meantime, the best I can suggest is to target mips2 and O32. That 
> combination will work and will do the same thing (aside from the 
> precise ELF header flags) as mips3 and O32 would.
>
> > How can I change the *fp=64* to *fp=32*? Have tried pass -mfp32 to 
> mipsel-unknown-linux-gnu-clang++ but with no luck.
>
> In the current implementation, this is not possible.
>
> This also raises a point I haven't considered yet. The Mips3 
> architecture mandates that the FPU implementation is 64-bit, but if 
> you're generating O32 code should we treat it as being a 32-bit FPU? I 
> suspect we should since it matches the treatment of GPR's.
>
> > Yes I known it works if uses *-mips64* etc, but I need mips3.
>
> I'd be surprised if mips64 and O32 works. It's subject to the same 
> problems as mips3 and O32.
>
>
Hi,
> the best I can suggest is to target mips2 and O32
It's not work for all, still get Assembler messages error on some source 
files
> Warning: float register should be even, was 7
> I'd be surprised if mips64 and O32 works.
I mean compile the code only, since running the application with buggy 
GUI. :-(

-- 
/Regards/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150616/bb1144d7/attachment.html>

> > the best I can suggest is to target mips2 and O32
> > It's not work for all, still get Assembler messages error on some
source files
>
> Warning: float register should be even, was 7
Could you add –save-temps to the compiler command and send me the command along
with the .i and .s file the compiler produces?

This warning is usually related to something called FPXX. FPXX is an extension
to the O32 ABI that causes the compiler to generate objects that can be used on
both a 32-bit and 64-bit FPU. In recent compilers it is enabled by default. The
most likely cause of the warning is some inline assembly that doesn't obey
the small restrictions that FPXX enforces. Assuming, this is the cause
–mfp32/-mfp64 should provide a work around but I'd recommend updating the
inline assembly since this will make it easier to port to newer Mips processors.

From: Weitian Leung [mailto:weitianleung at gmail.com]
Sent: 16 June 2015 08:01
To: Daniel Sanders; llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] How to pick default floating point ABI?

On 06/12/2015 07:12 PM, Daniel Sanders wrote:
Hi,

I'm afraid targeting a 64-bit CPU and the O32 ABI is completely broken at
the moment, it's one of the very long-standing issues I'm working
towards. The main problem is that a lot of the internals of the Mips LLVM
backend derive their behaviour from the target CPU rather than the target ABI.
In theory, the combination of mips3 and O32 is valid and should generate code
pretty much the same way as mips2 and O32 does. In the current implementation,
the fact that mips3 has 64-bit GPR's tells a lot of the code generator to
use 64-bit instructions and selects other behaviour that is correct for the
N32/N64 ABI's but not for O32. For this (and many other) reasons,
there's an assertion that O32 is not used on a 64-bit CPU.

Any patches that make progress on this will be warmly welcomed. In the meantime,
the best I can suggest is to target mips2 and O32. That combination will work
and will do the same thing (aside from the precise ELF header flags) as mips3
and O32 would.
> How can I change the fp=64 to fp=32? Have tried pass -mfp32 to
mipsel-unknown-linux-gnu-clang++ but with no luck.

In the current implementation, this is not possible.

This also raises a point I haven't considered yet. The Mips3 architecture
mandates that the FPU implementation is 64-bit, but if you're generating O32
code should we treat it as being a 32-bit FPU? I suspect we should since it
matches the treatment of GPR's.
> Yes I known it works if uses -mips64 etc, but I need mips3.
I'd be surprised if mips64 and O32 works. It's subject to the same
problems as mips3 and O32.


Hi,

the best I can suggest is to target mips2 and O32
It's not work for all, still get Assembler messages error on some source
files

Warning: float register should be even, was 7


I'd be surprised if mips64 and O32 works.
I mean compile the code only, since running the application with buggy GUI. :-(
--
Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150616/57ba34f2/attachment.html>

On 06/16/2015 06:21 PM, Daniel Sanders wrote:
>
> > > the best I can suggest is to target mips2 and O32
>
> > > It's not work for all, still get Assembler messages error on
some
> source files
> >
>
> > Warning: float register should be even, was 7
>
> Could you add –save-temps to the compiler command and send me the 
> command along with the .i and .s file the compiler produces?
>
> This warning is usually related to something called FPXX. FPXX is an 
> extension to the O32 ABI that causes the compiler to generate objects 
> that can be used on both a 32-bit and 64-bit FPU. In recent compilers 
> it is enabled by default. The most likely cause of the warning is some 
> inline assembly that doesn't obey the small restrictions that FPXX 
> enforces. Assuming, this is the cause –mfp32/-mfp64 should provide a 
> work around but I'd recommend updating the inline assembly since this 
> will make it easier to port to newer Mips processors.
>
> //
Just tested with xercesc v3, got these warnings (sorry I said error 
message in last reply)
> DOMNodeIDMap.s:134: Warning: float register should be even, was 1
> DOMNodeIDMap.s:134: Warning: float register should be even, was 1
> DOMNodeIDMap.s:136: Warning: float register should be even, was 1
> DOMNodeIDMap.s:141: Warning: float register should be even, was 1
> DOMNodeIDMap.s:148: Warning: float register should be even, was 1
> DOMNodeIDMap.s:758: Warning: float register should be even, was 1
> DOMNodeIDMap.s:758: Warning: float register should be even, was 1
> DOMNodeIDMap.s:759: Warning: float register should be even, was 1
> DOMNodeIDMap.s:764: Warning: float register should be even, was 1
> DOMNodeIDMap.s:771: Warning: float register should be even, was 1
Hope this helps.

-- 
/Regards/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150616/9858cd5c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_xercesc3_clang_mips2.tar.xz
Type: application/x-xz
Size: 53364 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150616/9858cd5c/attachment.bin>