This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Merge to trunk from Graphite branch
On Mon, Mar 15, 2010 at 2:46 PM, Jack Howarth <howarth@bromo.med.uc.edu> wrote:
> On Mon, Mar 15, 2010 at 02:32:58PM +0100, Richard Guenther wrote:
>> On Mon, Mar 15, 2010 at 2:12 PM, Jack Howarth <howarth@bromo.med.uc.edu> wrote:
>> > Richard,
>> > ? ?Dominique Dhumieres tried adding those two additional passes and
>> > they didn't help -fgraphite-identity stop dropping vectorizations.
>> > Shouldn't PR43359 be a P1 since this represents a regression from
>> > gcc 4.4?
>>
>> No.
>>
>> Richard.
>
> Richard,
> ? ?What exactly is the road-map for graphite to be enabled by
> default in FSF gcc? It seems that vectorization improvements
> have been treading water lately and that the biggest win so far
> for 4.5 has been HJ Lu's update of the default x86 arch. Hopefully
> we won't end up having to rely on milepost for future FSF gcc
> code performance improvements.
Sorry, but the biggest win for 4.5 is the various improvements
SUSE / AMD has contributed to improve SPEC CPU 2006 scores
(7% overall SPEC FP improvement).
Updating the default x86 arch does bring you nothing (well, if
you're not clueless in case you shouldn't build GCC yourself).
As far as I know Graphite does not bring any performance advantages
yet, so I see no reason to enable it by default.
If you want a specific benchmark to run faster you have to start
analyzing why it is slow (it helps to have a competing compiler
generate faster code), produce a testcase and at least file
a missed-optimization bugreport. Of course even better if you
can think of a solution and implement it.
I am not aware of any major vectorization missed-optimizations
vs for example the Intel compiler for SPEC CPU 2006.
Richard.
>> > ? ? ? ? ? ? ? ? ? ?Jack
>