On Fri, Dec 30, 2016 at 08:40:11PM +0300, Alexander Monakov wrote:
> Hello, Richard, Jakub, community,
>
> May I join/restart the old discussion about machine mode remapping at LTO
> stream-in time. To recap, when offloading to NVPTX was introduced, there
> was a problem due to differences in the set of supported modes (e.g. there
> was no 'XFmode' on NVPTX that would correspond to 'long double' tree type
> node in GIMPLE LTO streams produced by x86 host compiler).
>
> The current solution in GCC is to additionally stream a 'mode table' and use
> it
> to remap numeric mode identifiers during LTO stream-in in all trees that have
> modes. This is the solution initially outlined by Jakub in the message
> https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00226.html . In response to
> that,
> Richard said,
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. 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.
Jakub
