Possible bug? Register classes and FP64 on targets with no FP64 support

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