[Bug tree-optimization/92738] [10 regression] Large code size growth for -O2 binaries between 2019-05-19...2019-05-29

[wilco at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92738

--- Comment #11 from Wilco <wilco at gcc dot gnu.org> ---
(In reply to Thomas Koenig from comment #10)
> (In reply to Martin Liška from comment #6)
> > So wrf grew starting with r271377, size (w/o debug info) goes from 20164464B
> > to 23674792.
> 
> I think we've had this discussion before, although I cannot offhand
> recall the PR number.  PR91512 is closely related.
> 
> Since r271377, arguments which may be contiguous are now (conditionally)
> packed and unpacked inline (see PR88821).
> 
> This was done so that the middle end can look into these conversions
> and possibly eliminate them, if it can be determined via inlining
> or LTO that the argument is contiguous anyway). This can lead to an
> extremely large performance boost for some test cases (*10 or more),
> but will, in general, lead to a size increase.
> 
> Now, wrf has an extremely strange (and rare) programming style where they
> pass
> a ton of assumed shape arguments (where it is not clear, at compile-time,
> if they need packing/unpacking) to an old-style array argument. This
> causes considerable code size increase.
> 
> So, it's a tradeoff, which we discussed at the time. This is why this
> is not done at -Os.
> 
> Should we "fix" this? I think not, the style of wrf is just too horrid,
> and pessimizing other programs for the sake of one benchmark makes little
> sense to me.

Would using -frepack-arrays solve this issue? I proposed making that the
default a while back. It would do any repacking that is necessary at call sites
rather than creating multiple copies of all loops in every function.