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

[Richard Biener <rguenther at suse dot de>]

On Mon, 9 Jan 2017, Alexander Monakov wrote:

> 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.

In general I think they should match.  But without seeing concrete 
examples of where they do not I can't comment on whether such exceptions
make sense.  For example if you adjust a DECLs alignment and then
re-layout it I'd expect you might get a non-BLKmode mode for an
aggregate in some circumstances -- but then decl and type are not 1:1
compatible (due to different alignment), but this case is clearly desired
as requiring type copies for the sake of alignment would be wasteful.

Generally all "redundancies" we have in decls vs. types expose the
possibility of conflicting/non-matching information.

> 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.

The most simplistic solution would be to have a real_format * field in the
type (currently there's only a global mode-to-real_format mapping).  All
types are currently tree_type_non_common (huh), so there's some candidates
to put that info on (TYPE_BINFO, though that's used as TYPE_LANG_SLOT_1 - 
ugh, TYPE_VALUES looks unused though).

> 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 compiler.

So add a hack ontop of the hack?  Ugh.  So why exactly doesn't it
already work?  It looks like decls and types have their modes
"fixed" with the per-file mode table at WPA time.  So what is missing
is to "fix" modes in the per-function sections that are not touched
by WPA?

Richard.

> Thanks.
> Alexander
> 
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)