Deficiencies in GCC's code generator and optimiser

https://skanthak.hier-im-netz.de/gcc.html

by worik • 2 years ago

30 21 2 years ago

skanthak.hier-im-netz.de

worik• 2 years ago

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...

dataflow• 2 years ago

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

cozzyd• 2 years ago

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

/tinfoil

userbinator2• 2 years ago

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

pvg• 2 years ago

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

gcc145• 2 years ago

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.

vkaku• 2 years ago

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

pajko• 2 years ago

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

5436436347• 2 years ago

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.

chrsig• 2 years ago

getting a SSL_ERROR_RX_RECORD_TOO_LONG error trying to load the page

metadat• 2 years ago

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

devbent• 2 years ago

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

pubby• 2 years ago

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.

userbinator2• 2 years ago

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.

mrfart• 2 years ago

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.

russdill• 2 years ago

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.

hudsonwillis• 2 years ago

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.

kazinator• 2 years ago

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.)

joosters• 2 years ago

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?

Deficiencies in GCC's code generator and optimiser

Related Stories