llvm dev - Sep 2020 - [clang] What is the rationale behind locking the __int128 extension type behind a 64-bit pointer type?

On Sun, Sep 27, 2020 at 11:08:50AM +0100, Charlotte Delenk via llvm-dev
wrote:
> I have recently tried out the __int128 support in clang and one thing that
> bugged me was how it didn't work on 32 bit platforms. This limitation
didn't
> exist in other LLVM-based compilers like rustc and after removing the
> requirement the code generated seemed to be reasonable.
It is inherited from GCC. There is no matching type for the libgcc/crt
function naming convention either, which is a problem for division.

Joerg

Hello everyone,

I have recently tried out the __int128 support in clang and one thing 
that bugged me was how it didn't work on 32 bit platforms. This 
limitation didn't exist in other LLVM-based compilers like rustc and 
after removing the requirement the code generated seemed to be reasonable.

So now i'm asking for the rationale behind this descision. Is it because 
the ABI is incompatible? LLVM seems to lower i128 to 4 32-bit arguments 
in the function calling sequence. However that seems more like something 
LLVM should worry about and not clang?

many sysv ABI processor supplements don't seem to specify a 128 bit type 
and how it should be treated, but for example on powerpc llvm assigns it 
to 4 consecutive 32 bit registers while long doubles (which are 2 
doubles) are passed by address.

The only other rationale i can come up with is the lack of demand and 
the performance problems of types 4x the native word size