Re: [PATCH] x86: Align jump targets to 1 byte boundaries

Maciej W. Rozycki
2015-04-12T23:44:59Z

On Fri, 10 Apr 2015, Linus Torvalds wrote:

> It turns out that gcc's -Os is just horrible nasty crap. It doesn't
> actually make good tradeoffs for code density, because it doesn't make
> any tradeoffs at all. It tries to choose small code, even when it's
> ridiculously bad small code.
>
> For example, a 24-byte static memcpy is best done as three quad-word
> load/store pairs. That's very cheap, and not at all unreasonable.
>
> But what does gcc do? It does a "rep movsl".
>
> Seriously. That's *shit*. It absolutely kills performance on some very
> critical code.
>
> I'm not making that up. Try "-O2" and "-Os" on the appended trivial
> code. Yes, the "rep movsl" is smaller, but it's incredibly expensive,
> particularly if the result is partially used afterwards.
>
> And I'm not a hater of "rep movs" - not at all. I think that "rep
> movsb" is basically a perfect way to tell the CPU "do an optimized
> memcpy with whatever cache situation you have". So I'm a big fan of
> the string instructions, but only when appropriate. And "appropriate"
> here very much includes "I don't know the memory copy size, so I'm
> going to call out to some complex generic code that does all kinds of
> size checks and tricks".
>
> Replacing three pairs of "mov" instructions with a "rep movs" is insane.
>
> (There are a couple of other examples of that kind of issues with
> "-Os". Like using "imul $15" instead of single shift-by-4 and
> subtract. Again, the "imul" is certainly smaller, but can have quite
> bad latency and throughput issues).
>
> So I'm no longer a fan of -Os. It disables too many obviously good
> code optimizations.

I think the issue is -Os is a binary yes/no option without further tuning
as to how desperate about code size saving GCC is asked to be. That's
what we'd probably have with speed optimisation too if there was only a
single -O GCC option -- equivalent to today's -O3. However instead GCC
has -O1, -O2, -O3 that turn on more and more possibly insane optimisations
gradually (plus a load -f options for further fine tuning).

So a possible complementary solution for size saving could be keeping -Os
as it is for people's build recipe compatibility, and then have say -Os1,
-Os2, -Os3 enabling more and insane optimisations, on the size side for a
change. In that case -Os3 would be equivalent to today's -Os. There
could be further fine-tune options to control things like the string moves
you mention.

The thing here is someone would have to implement all of it and I gather
GCC folks have more than enough stuff to do already. I'm fairly sure they
wouldn't decline a patch though. ;)

Maciej