2009 Update

[Marcel Moolenaar]

[combined response]

On Nov 7, 2009, at 5:08 PM, Peter Chubb wrote:

> Gelato put a lot of effort into imprving gcc for IA64 -- gcc 4.x is
> miles better than gcc 3.x -- but there's still a lot that could be done
> with low-level instruction scheduling.

My immediate concern is correctness. Improving SPECcpu20xx looks good
academically, but means nothing to me in the context of FreeBSD if it
means spending a lot time finding work-arounds for correctness bugs.

At this time we can't compile the kernel correctly when all debugging
options are removed and I think we actually have a more optimal OS
with a compiler that generates less-optimal, but correct code than
what we now have with GCC 4.2.1. I find that bizarre..

I would probably stick with GCC much more longer if it would at least
generate correct code. Nonetheless, any future improvements that people
may make, may not be usable by FreeBSD due to licensing anyway, so to
me it's not as simple as "just fix what's broken"...


On Nov 7, 2009, at 9:16 PM, C. Bergström wrote:

> Small notes..
>   a) PathScale doesn't currently support IA64

Another aspect, again specifically in the context of FreeBSD, is that
architecture support in PathScale (or Open64) is limited. As such,
it won't easily be the next system compiler. At this time LLVM has
the best chance of replacing GCC, if GCC is ever being replaced.
Alas, the LLVM project recently removed the ia64 backend due to lack
of support. Just my luck :-)

While PathScale (and Open64) are great compilers for in the ports
collection and I would be very happy to see that happen, I do need
to keep an eye out for any developments involving the system compiler
and I may be forced to work on that just to keep FreeBSD on ia64
viable without forking off...

>   b) I would like to merge in some code that would give us a near optimal CG for IA64.  That in combination with a couple other things would hopefully bring us in the same ballpark as the Intel IA64 compiler.  (Pure speculation as I don't know this target very well or current state of Intel compiler)

Speculation is the correct word: the Intel compiler utilizes data
and control speculation and achieves good results in certain cases
because of it. The use of explicit prefetch operations also helps
to prime the cache with good results.

The CG for Itanium in PathScale should utilize this as well to be
in the same ballpark as the Intel compiler. At least, that's what
I assume it should do. If the code comes from Open64, then I think
you'll be in the same ballpark. People (including Intel as part of
the ORC project) have done a great job.


On Nov 7, 2009, at 10:43 PM, Peter Chubb wrote:

> The reason we put so much effort into attempting to improve things is
> that most people will just try to run their code with the compiler(s)
> they already know.

I can see that. Then again, I also fail to see it. With autoconf
and libtool, compiler differences should be non-issues and the
only thing developers should do is actually write portable code.

I believe that there's an even deeper and darker consequence to
the statement that people just try with the compiler they already
know and that is that the assumptions embedded in the code about
the architecture are not expected to cause problems.

Itanium did cause a lot of code churn while porting code from
i386 to ia64 and it wasn't just for being 64-bit. Still a lot
of code uses 'int' for variables that are never negative when
'unsigned int' yields more optimal code simply because it avoids
an unnecessary sign-extension.

What I'm trying to say is that assumptions about the compiler are
just a part of the problem and it's probably a smaller problem
than assumptions embedded in the code that cause unique problems
on Itanium. Assumptions about the architecture may have a bigger
impact on the resulting performance than assumptions about the
compiler will have.

It's good to keep as much the same if so many things change, so
Gelato's work has been good and beneficial. I was more in touch
when I worked @HP then I am now, so I don't know all the good
Gelato has done.

-- 
Marcel Moolenaar
xcllnt at mac.com