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

["Maciej W. Rozycki" <macro@linux-mips.org>]

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