Repository navigation
[E-IFC] Complete Floating Point Type Support #357
Description
Add support for the floating point types not covered in #315 via a new IFC EdgFloatType extension type.
The affected EDG IL float types are:
"EdgFloatType": {
"size": 4,
"values": {
"0x0": "Float16",
"0x1": "Fp16",
"0x2": "Float32x",
"0x3": "Float64x",
"0x4": "Float80",
"0x5": "Float128",
"0x6": "StdBfloat16"
}
}
Activity
wchilders-nvidia commentedon Oct 23, 2026
@znoffel1 has done some work in this direction.
soroshsabz commentedon Oct 23, 2026
ITNOA
Would you like me to update my PR to support all these types? or submit another PR after merge #315 ? or internal implementation exists for those?
wchilders-nvidia commentedon Oct 23, 2026
@znoffel1 has like a 90% complete internal implementation of this + it requires understanding the
gen-ifc-maptooling (that I hope to publish more documentation about soon). I think I'd just narrow your PR to the standard types and then we'll take care of this aspect for you next week or so :-)soroshsabz commentedon Oct 23, 2026
Context from the verification behind #315, in case it's useful for scoping this (plus a couple of suggestions):
Which kinds actually bite in practice. In gnu/clang emulation modes the predefined type entry processing (
src/sys_predef.c) predeclares_Float16,_Float32x,_Float64x,__float80,__float128,__fp16, and__bf16into the global scope, so interfaces compiled in those modes exercise exactly the kinds listed here. #315 skips the predeclared typedefs in the IFC scope dump (they're recreated by the importer), so this extension matters for exported entities whose signatures use these types.Two round-trip hazards worth encoding decisions around (both observed while testing #315):
__fp16vs_Float16: different manglings, same size. C++20 modules: support gnu emulation modes and extended floating-point types #315 deliberately leavesfk_fp16unencodable for this reason; a distinctEdgFloatTypevalue solves it.__float128vs_Float128: same hazard class. Per the plan noted in C++20 modules: support gnu emulation modes and extended floating-point types #315 (wchilders' comment), the fundamentalfloat+bit128encoding is now reserved forfk_std_float128only, andfk_float128waits for this extension - so the table'sFloat128value slotting tofk_float128lines up nicely.Suggestion 1 - BFloat16 appears to be missing.
fk_std_bfloat16(predeclared as__bf16in gnu modes;std::bfloat16_tin C++23) isn't in theEdgFloatTypevalues table. Including it (e.g.,0x6) would close the last of the predeclared extended-float kinds for exported entities.Suggestion 2 - consider restricting the table to the non-std kinds.
Float16(fk_float16) overlaps with the fundamentalfloat+bit16encoding #315 uses for_Float16(the std kind). Reserving the extension for the kinds that have no fundamental encoding (Fp16,Float32x,Float64x,Float80,Float128, andBFloat16) keeps exactly one encoding per kind, which is the ambiguity-avoidance goal. Either way works; just noting the overlap.On process (responding to the "extend #315 or a new PR" question): #315 is deliberately scoped as the fix plus the standard-type encodings and is ready to merge; layering a vendor-extension type format onto it would grow its review surface. A separate PR referencing this issue seems cleaner - and given @znoffel1 has work in flight here, we'd rather not race it. We're happy to help where useful: e.g., extending the emulation-mode regression tests (export scenarios for
__fp16,_Float32x,__float128,__bf16) once the extension lands, or reviewing the writer/reader sides against the gnu/clang-mode matrix we used for #315.