On Mon, 2 Jan 2017, Jakub Jelinek wrote: > In my view mode is essential part of the type system. It (sadly, but still) > participates in many ABI decisions, but more importantly especially for > floating point types it is the main source of information of what the type > actually is, as just size and precision are nowhere near enough. > The precision/size isn't able to carry information like whether the type is > decimal or binary floating, what padding it has and where, what NaN etc. > conventions it uses. So trying to throw away modes and reconstruct them > looks conceptually wrong to me.
I wonder if it's possible to have a small tag in tree types to distinguish between binary/decimal/fixed-point types. For prototyping, I was thinking about just looking at the type name, because non-ieee-binary types have an easily recognizable prefix. For padding and NaN variability, can you point me on which targets the modes affect that? The "Machine Modes" chapter in the documentation doesn't give a hint (IFmode/KFmode are not documented there either). Alternatively, is reconstructing all modes necessary in the first place? On tree level GCC has explicit trees for all fundamental types like float_type_node. Is it possible to remap just those trees? Modes of composite types should be deducible, and modes of decls may be deducible from their types (not sure; why do decls have modes separately from their types, anyway?) > One can also just use > float __attribute__((mode (XFmode))) or float __attribute__((mode (TFmode))) > or float __attribute__((mode (KFmode))) or IFmode etc., how do you want to > differentiate between those? And I don't see how this can help with the > long double stuff for NVPTX offloading. If user uses 80-bit long double > (or mode(XFmode) floats/doubles) in his source, then as PTX only has SFmode > and DFmode (perhaps also HFmode?), the only way to get it working is through > emulation (whether soft-fp, or writing some emulation using double, > whatever). Pretending long double on the host is DFmode on the PTX side > just won't work, they have different representation. (yes, PTX spec has half floats, but GCC doesn't implement those on PTX today, and thus doesn't have HFmode now) For attribute-mode, I wasn't aware of KFmode/IFmode stuff; wherever the modes affect semantics without leaving any other trace in the type, leaving out the mode loses information. So either one keeps the modes, or adds sufficient tagging in the type tree. For long double, I think offloading to PTX should have the following semantics: size/alignment of long double matches those on host. Otherwise, storage layout of composite types won't match, and that's really bad. But otherwise long double is the same as double on PTX (so for offloading from x86-64 it has 64 bits of padding). This means that long double data is not transferable between accelerator and host, but otherwise gives the most sane semantics I can imagine. I think this implies that XFmode/TFmode don't need to exist on NVPTX to back long_double_type_node. Thanks. Alexander
