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