Re: LTO remapping/deduction of machine modes of types/decls

[Richard Biener <rguenther at suse dot de>]

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 <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)