[X86][clang] 128bit floating-point operations in x86 machines

[CoTinker]

testcase:

#include <fenv.h>
#include <stdlib.h>
#include <stdio.h>

int main (void)
{
  volatile __float128 a = 0x0.fffp-16382q, b = 0x0.fffp0q, c;
  c = a / b;
  if (fetestexcept (FE_UNDERFLOW | FE_INEXACT))
    printf("Fail1\n");
  if (c != 0x1p-16382q)
    printf("Fail2\n");
  exit (0);
}

compile command:

% clang test.c -o test -lm -m32
% ./test
Fail1
Fail2

compile in x86_64 will return normally, but x86 output Fail.
https://godbolt.org/z/vhdsMhd8d

[llvmbot]

@llvm/issue-subscribers-backend-x86

Author: Longsheng Mou (CoTinker)

testcase:

#include <fenv.h>
#include <stdlib.h>
#include <stdio.h>

int main (void)
{
  volatile __float128 a = 0x0.fffp-16382q, b = 0x0.fffp0q, c;
  c = a / b;
  if (fetestexcept (FE_UNDERFLOW | FE_INEXACT))
    printf("Fail1\n");
  if (c != 0x1p-16382q)
    printf("Fail2\n");
  exit (0);
}

compile command:

% clang test.c -o test -lm -m32
% ./test
Fail1
Fail2

compile in x86_64 will return normally, but x86 output Fail.
https://godbolt.org/z/vhdsMhd8d

[arsenm]

Technically you need to enable FENV_ACCESS for this program

[CoTinker]

Technically you need to enable FENV_ACCESS for this program

#pragma STDC FENV_ACCESS ON
It seems not work.

[CoTinker]

CC @RKSimon @phoebewang

[hstk30-hw]

@arsenm Hi, enable FENV_ACCESS still fail. Does FENV_ACCESS supported in m32 ?
https://godbolt.org/z/MsYTe1cPc

[hstk30-hw]

CC @brad0

[hstk30-hw]

https://godbolt.org/z/4KbaWcvsG

I see the asm, clang x86 with m32 abi is not compatible with libgcc.

[hstk30-hw]

CC @hvdijk

[arsenm]

@arsenm Hi, enable FENV_ACCESS still fail. Does FENV_ACCESS supported in m32 ? https://godbolt.org/z/MsYTe1cPc

I think it should work the same as x64

[hstk30-hw]

In fact, not work! I guess float128 (long double) not align to 16 in x86-32.
I'm reading the x86 isel dag->dag pass, maybe lowering mir gets mistake in the step.

[hstk30-hw]

Do you have any idea about this problem?
It seems a legacy.
https://lists.llvm.org/pipermail/llvm-dev/2016-December/108033.html
Seems no body care about x86-32? @arsenm

[arsenm]

Seems no body care about x86-32?

Correct

[hstk30-hw]

So sad :(

[jcranmer-intel]

In fact, not work! I guess float128 (long double) not align to 16 in x86-32. I'm reading the x86 isel dag->dag pass, maybe lowering mir gets mistake in the step.

__float128 in the i386 psABI has a 16-byte alignment, though __float128 is not long double on x86 (that's the 80-bit type in general).

[hstk30-hw]

What Info I get from gdb debug is that

in function SoftenFloatRes_Binary store the TypeListBeforeSoften to CallOptions.OpsVTBeforeSoften

https://github.com/llvm/llvm-project/blob/3bcb1f2bdd5c70b2ac4aff3290996486d9ae0236/llvm/lib/CodeGen/SelectionDAG/LegalizeFloatTypes.cpp#L188C1-L207C2

but not used in TargetLowering::LowerCallTo.

In this case,

f128 = fdiv t33, t36

t33, t36 is f128，after GetSoftenedFloat it transfer to i128. So in TargetLowering::LowerCallTo the align is from i128

[hstk30-hw]

https://godbolt.org/z/48GcPM5xM

If we disable sse, it failed in x86-64

[tgross35]

Just as a note, LLVM and GCC are ABI-incompatible on x86 MinGW. I think it is GCC doing the wrong thing here, opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054 (unrelated to this issue, but possibly relevant for testing)

[tgross35]

@beetrees clarified that this is a stack alignment issue in rust-lang/compiler-builtins#622 (comment):

The i686 issue appears to be an ABI issue: GCC aligns f128 arguments to 16 bytes on the stack, whereas Clang/LLVM does not. Looking at the 32-bit x86 System V ABI specification, GCC's behaviour appears to be correct:

Padding may be needed to increase the size of each parameter to enforce alignment according to the values in Table 2.1.

Table 2.1 specifies __float128 to have both 16 byte size and alignment https://www.uclibc.org/docs/psABI-i386.pdf