On Mon, 2 Jan 2017, Jakub Jelinek wrote: > 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,
My suggestion at that time isn't likely working in practice due to the limitations Jakub outlines below. The situation is a bit unfortunate but expect to run into more host(!) dependences in the LTO bytecode. Yes, while it would be nice to LTO x86_64->arm and ppc64le->arm LTO bytecode it very likely isn't going to work. > 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 > > -- Richard Biener <rguent...@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
