I apologize in advance if this is a bit long or off-topic, but you might be
interested to hear first-hand what some of current Sun customers have to say.
On Fri, 10 Mar 2006, Alexey Starovoytov wrote:
> On Fri, 10 Mar 2006, Steven Bosscher wrote:
> > On Friday 03 March 2006 02:46, Alexey Starovoy
> Alexey Starovoytov writes:
Alexey> I doesn't look that my opinion here worth even 1 cent,
Alexey> but here are few things:
...
Alexey> All of the above is done by sun compiler and gcc4ss (except openmp).
Alexey> A lot of other things are coming.
None of the items you listed are SP
On Fri, 2006-03-10 at 12:34 -0800, Alexey Starovoytov wrote:
> On Fri, 10 Mar 2006, David Edelsohn wrote:
>
> > > Alexey Starovoytov writes:
> >
> > > If Sun starts improving GCC backend now it will never be able to catch up
> > > with Sun's own backend.
> >
> > This is a completely ridicu
On Fri, 2006-03-10 at 14:06 -0800, Alexey Starovoytov wrote:
> 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 optimizat
On Mar 10, 2006, at 5:06 PM, Alexey Starovoytov wrote:
- prefetch
It rather hurts performance when I tried it. Check -xprefetch* flags
There is a new tree level prefetching pass on the mainline, maybe you
should try it again.
-- Pinski
On Mar 10, 2006, at 5:06 PM, Alexey Starovoytov wrote:
- value profiling
doesn't look anything is done
Done and already in 3.4.0 and improved for the tree level in 4.1.0.
- openmp
I think it needs to be fully platform dependent, but anyway.
Certainly would be interesting to compa
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 opi
On Fri, 10 Mar 2006, Steven Bosscher wrote:
> On Friday 03 March 2006 02:46, Alexey Starovoytov wrote:
> > We are pleased to announce the availability of GCC for SPARC (R) Systems
> > (GCCfss) at http://cooltools.sunsource.net/gcc/
>
> Instead of pleased, I'd be ashamed for announcing this. To me
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.
-- Pinski
On Fri, 10 Mar 2006, David Edelsohn wrote:
> > Alexey Starovoytov writes:
>
> > If Sun starts improving GCC backend now it will never be able to catch up
> > with Sun's own backend.
>
> This is a completely ridiculous assertion. Do you have any
> evidence to back this up? There is no r
On Fri, 10 Mar 2006, Eric Botcazou wrote:
> Eh, SPARC is not IA-64 so improving the SPARC back-end should not be more
> resource-consuming than designing and maintaining a hybrid compiler. If I'm
gcc4ss wasn't a big effort. gimple form made it easy for us.
> not mistaken, the gap is wide for FP
On Friday 03 March 2006 02:46, Alexey Starovoytov wrote:
> We are pleased to announce the availability of GCC for SPARC (R) Systems
> (GCCfss) at http://cooltools.sunsource.net/gcc/
Instead of pleased, I'd be ashamed for announcing this. To me
it feels like you're announcing with pride how you ri
> Alexey Starovoytov writes:
> If Sun starts improving GCC backend now it will never be able to catch up
> with Sun's own backend.
This is a completely ridiculous assertion. Do you have any
evidence to back this up? There is no reason that GCC could not intercept
Sun CC if some effo
> When you're a company like Intel with a relatively small gap between gcc
> on x86 and icl, it's worth improving the gcc backend, but on Sparc
> the gap is much wider, so the effort to bridge it may not be justified
> from a resource point of view.
Eh, SPARC is not IA-64 so improving the SPARC ba
On Thu, 9 Mar 2006, Daniel Berlin wrote:
>
> > > * Maybe it would be possible to perform further development on a vendor
> > > branch in the GCC svn repository? I'm not sure if this would require SC
> > > buy-in, though. Perhaps the changes might become acceptible for FSF GCC
> > > at some
> > * Maybe it would be possible to perform further development on a vendor
> > branch in the GCC svn repository? I'm not sure if this would require SC
> > buy-in, though. Perhaps the changes might become acceptible for FSF GCC
> > at some point in time; there have been discussions over at
On Thu, 9 Mar 2006, Rainer Orth wrote:
> Alexey Starovoytov <[EMAIL PROTECTED]> writes:
>
> > We are pleased to announce the availability of GCC for SPARC (R) Systems
> > (GCCfss) at http://cooltools.sunsource.net/gcc/
> >
> > GCCfss extends GCC to be able to use
> > the optimizing Sun(tm) Code Ge
Alexey Starovoytov <[EMAIL PROTECTED]> writes:
> We are pleased to announce the availability of GCC for SPARC (R) Systems
> (GCCfss) at http://cooltools.sunsource.net/gcc/
>
> GCCfss extends GCC to be able to use
> the optimizing Sun(tm) Code Generator for SPARC systems (SCGfss).
A couple of que
18 matches
Mail list logo
