https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92738
--- Comment #10 from Thomas Koenig <tkoenig at gcc dot gnu.org> --- (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.
