Sujet : Re: Downwardly Scalable Systems
De : invalid (at) *nospam* invalid.invalid (Richard Kettlewell)
Groupes : comp.miscDate : 15. Apr 2024, 18:40:16
Autres entêtes
Organisation : terraraq NNTP server
Message-ID : <wwvzftuv81r.fsf@LkoBDZeT.terraraq.uk>
References : 1 2 3 4 5
User-Agent : Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
not@telling.you.invalid (Computer Nerd Kev) writes:
D <nospam@example.net> wrote:
On Sun, 14 Apr 2024, Computer Nerd Kev wrote:
In fact in terms of memory and disk storage GCC keeps going
backwards that even for C/C++. Compiling large C/C++ programs with
-Os in ever newer GCC versions keeps producing ever bigger binaries
for unchanged code. Of course other compilers are available and I'm
not sure how other popular ones compare.
Why do they go backwards?
>
I'd be quite interested to find out as well. When it comes to the
more fine-tuned optimisation options (a set of which -Os enables),
the GCC documentation is often very lacking in detail, especially
when it comes to changes between versions.
Interesting question, and I don’t know the answer, but it’s not hard to
come up with a small concrete example.
https://godbolt.org/z/sG5d99v5zhas the same code compiled at -Os with three different versions, plus
-O2 for comparison, and it does get a bit longer somewhere between 9.1
and 11.1.
The longer code uses one extra register (ebp) and because it’s run out
of callee-owned registers it must generate a push/pop pair for it
(adding 2 bytes to a 90-byte function, in this case).
It’s not easily explainable why it would do so: the gcc 9.1 object code
happily uses eax for the same purpose, without having to shuffle else
anything around, since eax isn’t being used for anything else at the
time.
Perhaps worth a bug report.
-- https://www.greenend.org.uk/rjk/