This is the mail archive of the
mailing list for the GCC project.
Re: GCC for SPARC Systems
- From: Alexey Starovoytov <alexey dot starovoytov at sun dot com>
- To: Andrew Pinski <pinskia at physics dot uc dot edu>
- Cc: <gcc at gcc dot gnu dot org>, David Edelsohn <dje at watson dot ibm dot com>
- Date: Fri, 10 Mar 2006 14:06:13 -0800 (PST)
- Subject: Re: GCC for SPARC Systems
On Fri, 10 Mar 2006, Andrew Pinski wrote:
> On Mar 10, 2006, at 3:34 PM, Alexey Starovoytov wrote:
> > Few major infrastructure features needs to be done first.
> Like? Please give examples. If link time optimizations,
> that is already starting to be worked on.
I doesn't look that my opinion here worth even 1 cent,
but here are few things:
- inter-proc (link time) opt
I think LLVM is a better approach.
- 2nd link time opt
not re-optimization like above, but asm code optimizations.
Looks like LLVM is targeting that as well. Check -xlinkopt flag and BIT
- profile driven opt
Great progress in 4.1. I'm very interested to see how you can match
it with link time opts.
- value profiling
doesn't look anything is done
I think it needs to be fully platform dependent, but anyway.
Certainly would be interesting to compare with Sun's approach.
- struct reorg opts
very intersting item on gcc's todo list
- loop opts
Not sure what exactly is being done, but what I can see in 4.0 and 4.1
needs to be improved. Try -xloopinfo for verbosity.
It rather hurts performance when I tried it. Check -xprefetch* flags
- struct type aliasing
Great progress in 4.1, but still much behind Sun. Check -xalias_level flag
- auto parallelization
doesn't look anything is being done here. Check -xautopar
just compare it with Sun's -fsimple=2
- optimized inline assembler
All of the above is done by sun compiler and gcc4ss (except openmp).
A lot of other things are coming.
Also I don't want to start "tree vs orc" flame, but it seems that Sun's IR
is better suited for the above opts. Ok. Ok. It's not.
> -- Pinski