[LLVMdev] How to pick default floating point ABI?

[Weitian Leung]

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>