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.
