0

I am trying to use GNU decimal floats with NVCC and I get the following error:

/usr/include/c++/4.8/decimal/decimal(230): error: invalid argument to attribute "mode"

The affected line is the following:

typedef float __decfloat32 __attribute__((mode(SD)));

I assume that NVCC does not support SD as an argument for mode. Is there any workaround or it is just not possible with NVCC? The code works well when compiling for CPU.

How/where is this SD defined?

Thanks!

Update: I could find where SD is defined for GCC. Two great answers here:

What does GCC __attribute__((mode(XX)) actually do?

For GCC: gcc/gcc/machmode.def

/* Decimal floating point modes.  */ 
DECIMAL_FLOAT_MODE (SD, 4, decimal_single_format);
DECIMAL_FLOAT_MODE (DD, 8, decimal_double_format);
DECIMAL_FLOAT_MODE (TD, 16, decimal_quad_format);

Isolating the host code in a *.cpp file works ok. Once the code goes into a *.cu, NVCC is used and it doesn't compile anymore. I can keep device/host code apart but I was investigating how the GCC decimal library works internally in combination with NVCC.

Where can I find more information about NVCC connected to this?

Community
  • 1
  • 1
Juan Leni
  • 6,982
  • 5
  • 55
  • 87
  • Do you know what a decimal float is? Do you understand the **huge** performance impact? Since you apparently don't (have to) care about performance, the choice for NVCC is rather surprising. – MSalters Sep 15 '15 at 10:45
  • I perfectly understand what a decimal float is. There are some parts in my kernel where I need this. I definitely care about performance, though, there are certain applications where decimal types are useful/necessary. I also know that depending on the implementation branch divergence can be a problem. – Juan Leni Sep 15 '15 at 11:30
  • Ok, here's the point: outside of IBM mainframes there is no hardware of decimal floating point. Everyone uses binary floating point. Decimal floating point therefore has to be emulated. This is about 100x slower. Decimal floating point is somewhat useful for banking, and even there the better choice would be decimal _fixed_ point. Decimal floating point just gives you _different_ rounding results, but 1/3 still is rounded. – MSalters Sep 15 '15 at 11:39
  • Sorry but I knew all this already, including decimal fixed point, etc, etc... I can't discuss my application here. My question is about GCC / NVCC and the mode attribute. – Juan Leni Sep 15 '15 at 11:43
  • @mtk99 Are you trying to use `__decfloat32` in host code or device code? – njuffa Sep 15 '15 at 12:14
  • Isolating the host code in a *.cpp file works ok. Once the code goes into a *.cu, NVCC is used and it doesn't work anymore. I can keep them apart but I was investigating how the GCC decimal library works internally in combination with NVCC. – Juan Leni Sep 15 '15 at 12:18
  • I don't see how you can use `__decfloat32` in device code given that GPUs does not provide hardware support for decimal floating-point arithmetic, and NVIDIA doesn't provide an emulation library for decimal floating-point. Keeping platform specific host code in separate `.cpp` files instead of mixing it into `.cu` files is always advisable. – njuffa Sep 15 '15 at 12:22
  • It is not uncommon to keep host/device kernels in the same file and to use the host code for testing. Still, I can see that it is better to separate the implementations due to platform differences. Thanks. – Juan Leni Sep 15 '15 at 12:27
  • 2
    Note that I am only advocating that *platform-specific* host code be kept in separate `.cpp` files, not host code in general. Examples from my own work would be the use of x86 and ARM specific intrinsics in the host code. This case is similar as the declaration of `__decfloat` involves `gcc`-specific code. – njuffa Sep 15 '15 at 12:37

1 Answers1

1

The problem is that this line defines __decfloat32 as float __attribute__ mode((SD)). All these underscores indicate that you're using compiler-specific names. This is indeed the case: __decfloat32 is a GCC extension. This is useful primarily when GCC runs on an AIX system with decimal floating point hardware.

NVCC obviously doesn't target AIX. Even if they would implement the same __attribute__((mode)) as GCC did, they'd still restrict it to SF and DF. Even TF (128 bits) will be missing as that's not supported by NVidia. They're definitely not going to spent a few months implementing decimal floats, so mode(SD) won't be implemented either.

Still, I'm 99% sure that this is an XY problem. Decimal and binary floating point are both finite-precision approximations, and a 64 bit binary FP number is much more precise and much faster than a 32 bits decimal FP.

MSalters
  • 173,980
  • 10
  • 155
  • 350
  • This is not AIX specific. It works well with Intel CPUs. – Juan Leni Sep 15 '15 at 12:08
  • This is not an XY problem. I can't discuss my application. I do understand the implications of using DFP. I was just investigating details in GCC / NVCC and I do understand that Nvidia doesn't support DFP. – Juan Leni Sep 15 '15 at 12:14
  • 4
    If you understand it doesn't implement DFP, then why are you surprised it doesn't support mode(**S**ingle-precision **D**ecimal) ?! Or didn't you realize what the abbreviation means? – MSalters Sep 15 '15 at 12:16