This is the mail archive of the
gcc@gcc.gnu.org
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:14:34 +0100 (CET)
- Subject: Re: LTO remapping/deduction of machine modes of types/decls
- Authentication-results: sourceware.org; auth=none
- References: <alpine.LNX.2.20.13.1612302022360.2185@monopod.intra.ispras.ru> <20170102101931.GB21933@tucnak> <alpine.LNX.2.20.13.1701021755140.2523@monopod.intra.ispras.ru> <20170102155403.GE21933@tucnak> <alpine.LNX.2.20.13.1701022142000.2523@monopod.intra.ispras.ru> <20170102190255.GG21933@tucnak>
On Mon, 2 Jan 2017, Jakub Jelinek wrote:
> On Mon, Jan 02, 2017 at 09:49:55PM +0300, Alexander Monakov wrote:
> > On Mon, 2 Jan 2017, Jakub Jelinek wrote:
> > > If the host has long double the same as double, sure, PTX can use its native
> > > DFmode even for long double. But otherwise, the storage must be
> > > transferable between accelerator and host.
> >
> > Hm, sorry, the 'must' is not obvious to me: is it known that the OpenMP ARB
> > would find only this implementation behavior acceptable?
>
> long double is not non-mappable type in the spec, so it is supposed to work.
> The implementation may choose not to offload whenever it sees long
> double/__float128/_Float128/_Float128x etc.
>
> > Apart from floating-point types, are there other situations where modes carry
> > information not deducible from the rest of the tree node?
>
> Dunno about fixed types, partial ints etc., but it is mostly floating point
> types, sure.
Mostly floats I guess. But just to say it would be very nice to have
enough information in the trees so layout_type can re-construct the
mode. It already does for 99% of the types... (just grep for
SET_TYPE_MODE).
Richard.