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

[Richard Biener <rguenther at suse dot de>]

On Tue, 10 Jan 2017, Alexander Monakov wrote:

> On Tue, 10 Jan 2017, Richard Biener wrote:
> > 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.
> 
> Thanks; Vlad will follow up with (I believe) a different kind of mismatches
> originating in the C++ front-end.
> 
> > > 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?
> 
> WPA re-streams packed function bodies as-is, so anything referred to
> from within just the body won't be subject to mode remapping; I think
> only modes of toplevel declarations and functions' arguments will be
> remapped.  And I believe it wouldn't be acceptable to unpack/remap/repack
> function bodies at WPA stage (it's contrary to LTO scalability goal).

Yes indeed.  But this means the mode-maps have to be per function
section (with possibly a way to "share" them?).  Or we need a way
to annotate function sections with "no need to re-map" as the
native nvptx sections don't need remapping and the others all use
the same map?

Richard.