[libc-commits] [libc] [llvm] [libc] Provide `LIBC_TYPES_HAS_INT128` (PR #84149)

[via libc-commits]

lntue wrote:

> > > > > @lntue should we also provide aliases (`using int128_t = __int128_t`) as we do for `_Float16` et al.?
> > > > > It looks to me like it would be more consistent.
> > > > 
> > > > 
> > > > For us, shall the alias be `uint128` instead, similar to `float16`, just in case `uint128_t` is standardized in the future?
> > > 
> > > 
> > > I was suggesting something like the following in `types.h`
> > > ```
> > > // int128 / uint128 support
> > > #if defined(__SIZEOF_INT128__)
> > > #define LIBC_TYPES_HAS_INT128
> > > using uint128_t = __uint128_t;
> > > using int128_t = __int128_t;
> > > #endif // defined(__SIZEOF_INT128__)
> > > ```
> > > 
> > > 
> > >     
> > >       
> > >     
> > > 
> > >       
> > >     
> > > 
> > >     
> > >   
> > > So we could provide both signed and unsigned. The aim is to use them as the other types (i.e., `uint64_t`) whenever they are available.
> > > And yes it would be only for internal usage.
> > 
> > 
> > My original intent was to distinguish between our internal one `(u)int128` with the possible (if standardized) spelling `(u)int128_t`. But now we are providing a complete `stdint.h` header, so I think it is ok to use `uint128_t` and `int128_t` for this. On the other hand, it might be at odds with `float16` and `float128` spellings.
> 
> Ha! Then I misunderstood your point. Right now the type would be available through `types.h`, if it gets standardized we'd have to add it to our `stdint.h` and guard it properly. Why would you want to distinguish between the two? They ought to have the same semantics anyways (same size, same alignment requirements).

That's fine for me.  And ideally it's only used for some type setup things, and all the internal computational usage should use the `UInt128` type instead, so that it works on all platforms.

https://github.com/llvm/llvm-project/pull/84149