Cygnus & Intel Donate ia32 gcc ia32 Backend

AT writes "Cygnus has released the source for a new x86 backend for gcc. The new code focuses on better PII optimization. Intel contracted the changes from Cygnus. The code isn't quite release quality yet, but it should be intergrated into gcc 2.9x source tree around August. " Hopefully this won't be an isolated incident considering the number of chips coming outta Intel in the not-so-distant-future.

Comments

Re:How fast is GCC these days

[Mr Z]

This is true for GCC 2.8. There's a new Sparc back-end in EGCS which should bring GCC into the latter half of the 90's finally.

One nice thing about the new back end is that it actually understands the Ultra-Sparc's scheduling requirements so that it can actually get four instructions issued each cycle. When you lump in the Haifa scheduler technology as well as the advanced pointer analysis and so on, I think 3.0 will shape up to be a much stronger contender.

In the meantime, I'd expect EGCS's performance numbers to still lag Sun's SparcWorks compiler for a little while, based on the following reasons:

• EGCS is still not widely deployed, and so there isn't alot of feedback available for tuning it.
• EGCS is still a work-in-progress, and many new bits are being added. It'll be awhile before they're all well-adjusted to work together. (Optimizations are NOT as linearly independent of each other as many would wish.)
• The SparcWorks compiler still has a few other features that are missing from EGCS, such as cache-based optimization. These can really help certain classes of programs.
• Finally, the benchmarks will always be skewed if we only consider SPEC. The Sun compilers are very much SPEC-oriented compilers, from what I've seen. While Sun may have a large lead on SPEC benchmarks, the real-world difference is quite a bit smaller, I'm sure.

So that's about it. I can't really comment on the C++ differences, except to say that I would imagine alot of the binary bloat comes from GCC having to "roll its own" exception handling and infrastructure, whereas Sun probably offloads alot of that to proprietary, platform-specific libraries.

--Joe

--

Re:Cool... but what about AMD?

[Mr Z]

It would appear Intel is trying to keep its x86 flavor more attractive than other x86 flavors by stacking the compilers in its favor as well. I might be cynical, but I think that Intel is banking on getting a few of the ducats that people are saving on Open-Source Software by having them upgrade to an Intel x86 instead of an AMD or Cyrix part.

After all, the compiler supports Intel-specific optimizations, so why not?

The problem, of course, is the fact that AMD and Cyrix probably do not have the resources to fund/promote similar efforts, so this does end up being a means for Intel to un-level the playing field.

On the bright side, alot of x86-specific tweaks will help all x86 variants, not just Intel's x86s. (For instance, register allocation that understands the highly non-orthogonal IA32 register file would be a big step forward for all x86's. There was an interesting paper in MICRO-31 about that, IIRC. Also, scheduling to avoid AGIs and other hazards generally helps all flavors.) So, the picture isn't as bad as the paragraph above might have painted.

Nonetheless, if you want AMD-specific tweaks to GCC, then why don't you see if you can contribute to the tweaking effort? Even if all that means is beta-testing proposed changes on your machine for robustness and performance improvements, it'll still help. Poke around egcs.cygnus.com and ask what's up.

--Joe

--