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

[Guillaume Chatelet via libc-commits]

gchatelet 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).

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