This is the mail archive of the
mailing list for the GCC project.
Re: LTO remapping/deduction of machine modes of types/decls
- From: Alexander Monakov <amonakov at ispras dot ru>
- To: Richard Biener <rguenther at suse dot de>
- Cc: Jakub Jelinek <jakub at redhat dot com>, gcc at gcc dot gnu dot org, Vladislav Ivanishin <vlad at ispras dot ru>
- Date: Mon, 9 Jan 2017 21:55:15 +0300 (MSK)
- Subject: Re: LTO remapping/deduction of machine modes of types/decls
- Authentication-results: sourceware.org; auth=none
- References: <alpine.LNX.email@example.com> <20170102101931.GB21933@tucnak> <alpine.LSU.firstname.lastname@example.org>
On Wed, 4 Jan 2017, Richard Biener wrote:
> 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.
Yes, I think it's not really practical to seek wide portability of LTO bytecode.
After all, platform specifics get into constant expressions (e.g. 'int p =
sizeof (void *);') and are also observable on the preprocessor level (e.g. via
'#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__').
However the accelerator platform must be compatible with the host platform in
almost all ABI (storage layout?) features such as type sizes and alignments,
endianness, default signedness of char, bitfield layout, and possibly others
(but yet in the other subthread I was arguing that compromising and making
'long double' only partially compatible makes sense). Thus, portability issue
is much smaller in scope here.
I think it's a bit unfortunate that the discussion really focused on the trouble
with floating-point types. I'd really appreciate any insight on the other
questions that were raised, such as whether the decl mode should match that
decl's type mode.
For floating types, I believe in the long run it should be possible to tag tree
type nodes with the floating-point type 'kind' such as IEEE binary, IEEE
decimal, accum/fract/sat, or IBM double-double.
For our original goal, I think we'll switch to the other solution I've outlined
in the opening mail, i.e. propagating mode tables at WPA stage and keeping
enough information to know if the section comes from the host or native