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.
