This is the mail archive of the
mailing list for the GCC project.
Re: LTO remapping/deduction of machine modes of types/decls
- From: Richard Biener <rguenther at suse dot de>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Alexander Monakov <amonakov at ispras dot ru>, gcc at gcc dot gnu dot org, Vladislav Ivanishin <vlad at ispras dot ru>
- Date: Wed, 4 Jan 2017 11:04:41 +0100 (CET)
- Subject: Re: LTO remapping/deduction of machine modes of types/decls
- Authentication-results: sourceware.org; auth=none
- References: <alpine.LNX.firstname.lastname@example.org> <20170102101931.GB21933@tucnak>
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.
Richard Biener <email@example.com>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)