Deficiencies in GCC's code generator and optimiser | Hacker News Reader

Deficiencies in GCC's code generator and optimiser

skanthak.hier-im-netz.de

30 pointsworik21 comments

A few notes:

1) a good deal of time is spent talking about the performance of libgcc builtins for operations that are implemented in hardware. this is silly, these are not going to be used.

2) performance of some builtins related to 128-bit integers does seem to be suboptimal (pretty hard to evaluate this since it mostly says "terrible code" without explanation, though alot of the stuff seems to be related to the register allocator/prologue)

3) Case 24 is allowed because the code itself has UB

4) Case 27 is wrong - cmov is implemented on x86 processors. given that he uses mtune instead of march, this is another error.

While there do seem to be a couple genuine issues pointed out here, most of this article seems like mean-spirited hogwash.

cmov was first introduced on the Pentium Pro, i686. gcc should be able to produce code for i386, but all the distro's have since moved to a default target of P4 iirc. As you say, -mtune is not the correct compiler flag for this purpose.

Trying to write a perfect optimizer is like trying to slay a hydra. Every time you address one weakness, two more are spotted. The overall approach has to run in polynomial time (or close to it), so there will always be missed optimization chances.

And then half the time it's just your compiler being stupid.

> gcc -DCTZ -m32 -mtune=i386 -o- -O3 -S case27.c

> ...

> OUCH: the CMOVcc instruction is not available on the i386 processor!

To "tune" for a processor isn't the same thing as to "target" that processor.

In other words -mtune isn't a substitute for -mcpu; it is independent. When -mcpu is used, it implies some tuning as if -mtune were used, but -mtune overrides that.

Except for exploring compiler behavior, it doesn't make sense to tune for i386 while generating instructions for a much newer chip in that family; but it looks like it may be the GCC invoker's responsibility to get their ducks in a row here by using a combination of options that makes sense.

(Sure, would be better if there was a detection for that and diagnostic.)

Interesting article. I investigated a few mentioned cases and here're my thoughts:

1. Pretty much all libgcc builtins (especially those manipulating integers/i128/bits) are known to be not super optimized and probably not well maintained to latest architecture. All places I worked use libdivide and other hand-rolled implementations rather than __addvti3

2. Many 32-bit inefficient compilations work correctly on amd64 platforms. Perhaps it's the lack of maintenance on 32-bit platforms?

3. When using two intrinsic in the same function, it's almost always slower than a hand-crafted snippet implementing the same semantic. Compilers aren't smart enough in this case.

This stuff should be on the Bugzilla. GCC developers act on them.

Neither the gcc version, nor the compiler parameters were specified.

He mentioned in spots GCC 9.1 was used, albeit still missing parameters. This is odd to test considering how old it is and how the .1 release is not the last bugfix release for the 9 series.

Edit: I see the 9.1 reference is itself referencing related work, and not a source for his assembly outputs.

Thousands of words written about how, specifically, gcc produces poor slow code ('the application users' time is more valuable than their time') and yet the article never tries to measure how slow or fast any of their examples are.

I mean, maybe it is true that gcc is bad, maybe it isn't, but complaining that a function takes 27 bytes and it could have been written in 25 is missing the point entirely when you are asking for speed. Does it run fast or not?

Some of those look like the output of a superoptimiser, which would be difficult to implement in generality in a compiler like GCC.

Also, by attaching a "license" to such short sequences of code, you may have unknowingly caused those worried about legal concerns to shy away from getting their compiler to generate them.

getting a SSL_ERROR_RX_RECORD_TOO_LONG error trying to load the page

What's your browser? Works ok for me on Android with Brave.

That website is so sus my browser (chrome android) and my ISP blocked it...

I am not qualified to evaluate this

I came across it on the Motion mailing list, someone making the claim that GCC has been deliberately sabotaged

I think that is a borderline crazy idea, but as I say I an not qualified...

Before we even get to evidence... what would the motive for such a thing be?

energy company trying to make more profit (also why Electron and Python exist).

/tinfoil

Commercial competitors? I can definitely see a motive, if not evidence.

But notice that the author also believes that clang is being sabotaged as well, by the same commercial competitors.

They're scheming on a thing that's a mirage?

For reference, this is the mail that made the rounds (got it on musl ml).

https://www.openwall.com/lists/musl/2024/03/24/17

The claims do seem to be sane at a glance, so it's too bad it's hard to take them seriously with the conspiracy-theory envelope it's wrapped in.

The technical claims (that some optimizations could be better) appear to be correct. But the author seems to seriously lack interpersonal skills (trashes projects and people and then is surprised when he gets hostile responses), and the theory of deliberate sabotage is complete lunacy.

What interest could Apple and Microsoft have in sabotaging their own compiler performance? (Intel would at least have a theoretical motive, but their compiler is quite good). As for gcc, the past has shown that the community is perfectly capable of forking the project if they perceive it to be neglected / mistreated. So the more likely explanation is that these optimizations are not that easy to implement correctly.

If it were that easy, nothing stops the author from forking gcc and putting in the optimizations themselves.

Reply on news.ycombinator.com