[llvm-dev] Possible bug? Register classes and FP64 on targets with no FP64 support

[Martin J. O'Riordan via llvm-dev]

Anybody got any ideas about this?  Implementing FP64 support on a system
with no native FP64 capabilities?

 

I would have expected that it was more-or-less like supporting INT64 on a
system that only natively supported INT32, where the compiler abstracts the
INT64 into a pair of?

 

I am seeing the 'compiler-rt' support library functions being called for
fundamental operations such as ADD-FP64 and DIV-FP64 using a pair of INT32s,
but simple assignment appears to want to allocate physical FP64 registers!
Is this a bug?

 

Other than specifying that the DataLayout is 64-bit size and 64-bit
alignment ('-f64:64'), and that 'long double' is IEEEdouble, I have not said
anything else about FP64, expecting the compiler to fall-back on a default
Compiler-RT supported implementation.  I have the following specified in
'Targets.cpp':

 

LongDoubleWidth = 64u;

LongDoubleAlign = 64u;

LongDoubleFormat = &llvm::APFloat::IEEEdouble;

 

It seems odd that the compiler falls back on a 2 x INT32 representation for
most things (add, sub, div, mul, fp64-int, int-fp64, etc.), but not simple
assignment.

 

When we implemented INT64 on our INT32 architecture, we originally accepted
the default 2 x INT32 solution that compiler provided where there were no
INT64 registers.  This was fine, except for efficiency.  Later we added an
'i64' register class hoping to be able to make Load/Store legal, but
unfortunately this had the unexpected impact of us also having to provide
lowering solutions for things that 'compiler-rt' was already doing perfectly
well.  But I am nervous of having to face the more complex requirement to
re-implement as "lowering" specialisations ,those things that 'compiler-rt'
already does perfectly well for FP64.

 

Thanks,

 

            MartinO 

 

From: Martin J. O'Riordan [mailto:martin.oriordan at movidius.com] 
Sent: 29 September 2016 11:39
To: 'LLVM Developers' <llvm-dev at lists.llvm.org>
Subject: Register classes and FP64 on target with no FP64 support

 

Hi LLVM-Dev,

 

I am trying to implement support for emulated FP64 on our target.  Many
operations work fine, invoking the appropriate helper function in
'compiler-rt'.  But we don't have a specific register class for FP64 and
LLVM usually selects a pair of 32-bit integers, which is fine.  The problem
is that it doesn't "always" select a pair of 32-bit integers, and then I get
an assertion in 'TargetRegisterInfo::getMinimalPhysRegClass' that says
"Couldn't find the register class".

 

The funny thing is that something like 'a = b * c;' works perfectly, but the
much simple 'a = b;' causes this assertion.

 

We have not used 'setOperationAction' for any of the FP64 operations, nor
have we created a special register class for them either, in the expectation
that it would just reduce to the underlying integers and 'compiler-rt'
calls.

 

I'm a bit stumped, so does anyone have any advice about how I should
describe our target so that it supports emulated FP64 using either a pair of
32-bit integers or a single 64-bit register as the underlying implementation
type?

 

Thanks,

 

            MartinO - Movidius

 

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