Messages in this thread | | | Date | Mon, 13 Apr 2015 00:44:53 +0100 (BST) | From | "Maciej W. Rozycki" <> | Subject | Re: [PATCH] x86: Align jump targets to 1 byte boundaries |
| |
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
| |