On Thu, 27 Jul 2023, Jakub Jelinek via Gcc-patches wrote: > - _BitInt(N) bit-fields aren't supported yet (the patch rejects them); I'd > like > to enable those incrementally, but don't really see details on how such > bit-fields should be laid-out in memory nor passed inside of function > arguments; LLVM implements something, but it is a question if that is what > the various ABIs want
So if the x86-64 ABI (or any other _BitInt ABI that already exists) doesn't specify this adequately then an issue should be filed (at https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues in the x86-64 case). (Note that the language specifies that e.g. _BitInt(123):45 gets promoted to _BitInt(123) by the integer promotions, rather than left as a type with the bit-field width.) > - conversions between large/huge (see later) _BitInt and _Decimal{32,64,128} > aren't support and emit a sorry; I'm not familiar enough with DFP stuff > to implement that Doing things incrementally might indicate first doing this only for BID (so sufficing for x86-64), with DPD support to be added when _BitInt support is added for an architecture using DPD, i.e. powerpc / s390. This conversion is a mix of base conversion and things specific to DFP types. For conversion *from DFP to _BitInt*, the DFP value needs to be interpreted (hopefully using existing libbid code) as the product of a sign, an integer and a power of 10, with appropriate truncation of the fractional part if there is one (and appropriate handling of infinity / NaN / values where the integer part obviously doesn't fit in the type as raising "invalid" and returning an arbitrary result). Then it's just a matter of doing an integer multiplication and producing an appropriately signed result (which might itself overflow the range of representable values with the given sign, meaning "invalid" should be raised). Precomputed tables of powers of 10 in binary might speed up the multiplication process (don't know if various existing tables in libbid are usable for that). It's unspecified whether "inexact" is raised for non-integer DFP values. For conversion *from _BitInt to DFP*, the _BitInt value needs to be expressed in decimal. In the absence of optimized multiplication / division for _BitInt, it seems reasonable enough to do this naively (repeatedly dividing by a power of 10 that fits in one limb to determine base 10^N digits from the least significant end, for example), modulo detecting obvious overflow cases up front (if the absolute value is at least 10^97, conversion to _Decimal32 definitely overflows in all rounding modes, for example, so you just need to do an overflowing computation that produces a result with the right sign in order to get the correct rounding-mode-dependent result and exceptions). Probably it isn't necessary to convert most of those base 10^N digits into base 10 digits. Rather, it's enough to find the leading M (= precision of the DFP type in decimal digits) base 10 digits, plus to know whether what follows is exactly 0, exactly 0.5, between 0 and 0.5, or between 0.5 and 1. Then adding two appropriate DFP values with the right sign produces the final DFP result. Those DFP values would need to be produced from integer digits together with the relevant power of 10. And there might be multiple possible choices for the DFP quantum exponent; the preferred exponent for exact results is 0, so the resulting exponent needs to be chosen to be as close to 0 as possible (which also produces correct results when the result is inexact). (If the result is 0, note that quantum exponent of 0 is not the same as the zero from default initialization, which has the least exponent possible.) -- Joseph S. Myers jos...@codesourcery.com
