* Some regressions from the dataflow merge
@ 2007-06-12 11:48 Richard Guenther
2007-06-12 14:05 ` Kenneth Zadeck
2007-06-12 19:10 ` Richard Guenther
0 siblings, 2 replies; 16+ messages in thread
From: Richard Guenther @ 2007-06-12 11:48 UTC (permalink / raw)
To: gcc; +Cc: zadeck
On ia64 SPEC2000 I see fma3d and applu now miscompare, and we have
on x86_64 some performance regressions with Botan (a collection of
cryptographic algorithms (see
http://www.suse.de/~gcctest/c++bench/botan/)) - those are reasonably
small enough to investigate, but wait another day in case its just noise.
Otherwise things look smooth as expected.
Richard.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Some regressions from the dataflow merge
2007-06-12 11:48 Some regressions from the dataflow merge Richard Guenther
@ 2007-06-12 14:05 ` Kenneth Zadeck
2007-06-12 14:09 ` Richard Guenther
2007-06-12 14:35 ` Dave Korn
2007-06-12 19:10 ` Richard Guenther
1 sibling, 2 replies; 16+ messages in thread
From: Kenneth Zadeck @ 2007-06-12 14:05 UTC (permalink / raw)
To: Richard Guenther; +Cc: gcc
Richard Guenther wrote:
> On ia64 SPEC2000 I see fma3d and applu now miscompare, and we have
> on x86_64 some performance regressions with Botan (a collection of
> cryptographic algorithms (see
> http://www.suse.de/~gcctest/c++bench/botan/)) - those are reasonably
> small enough to investigate, but wait another day in case its just noise.
>
> Otherwise things look smooth as expected.
>
> Richard.
>
I looked at the graphs here and i do not see a regression except in the
compile time.
kenny
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Some regressions from the dataflow merge
2007-06-12 14:05 ` Kenneth Zadeck
@ 2007-06-12 14:09 ` Richard Guenther
2007-06-12 14:43 ` Kenneth Zadeck
2007-06-12 14:35 ` Dave Korn
1 sibling, 1 reply; 16+ messages in thread
From: Richard Guenther @ 2007-06-12 14:09 UTC (permalink / raw)
To: Kenneth Zadeck; +Cc: gcc
On Tue, 12 Jun 2007, Kenneth Zadeck wrote:
> Richard Guenther wrote:
> > On ia64 SPEC2000 I see fma3d and applu now miscompare, and we have
> > on x86_64 some performance regressions with Botan (a collection of
> > cryptographic algorithms (see
> > http://www.suse.de/~gcctest/c++bench/botan/)) - those are reasonably
> > small enough to investigate, but wait another day in case its just noise.
> >
> > Otherwise things look smooth as expected.
> >
> > Richard.
> >
> I looked at the graphs here and i do not see a regression except in the
> compile time.
Note the graphs are for Throughput, so higher numbers are better. Look
for example at Serpent or Skipjack at
http://www.suse.de/~gcctest/c++bench/botan/botan-summary.txt-1-0.html
(which has separate graphs for each algorithm). But as I said - just
wait a day to see if it is noise.
Richard.
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: Some regressions from the dataflow merge
2007-06-12 14:05 ` Kenneth Zadeck
2007-06-12 14:09 ` Richard Guenther
@ 2007-06-12 14:35 ` Dave Korn
2007-06-12 14:54 ` Kenneth Zadeck
1 sibling, 1 reply; 16+ messages in thread
From: Dave Korn @ 2007-06-12 14:35 UTC (permalink / raw)
To: 'Kenneth Zadeck', 'Richard Guenther'; +Cc: gcc
On 12 June 2007 15:05, Kenneth Zadeck wrote:
> Richard Guenther wrote:
>> On ia64 SPEC2000 I see fma3d and applu now miscompare, and we have
>> on x86_64 some performance regressions with Botan (a collection of
>> cryptographic algorithms (see
>> http://www.suse.de/~gcctest/c++bench/botan/)) - those are reasonably small
>> enough to investigate, but wait another day in case its just noise.
>>
>> Otherwise things look smooth as expected.
>>
>> Richard.
>>
> I looked at the graphs here and i do not see a regression except in the
> compile time.
Fortran has a testcase that trips one on x86/cygwin: see
http://gcc.gnu.org/ml/gcc/2007-06/msg00291.html. Perhaps you can comment on
whether df_live (== df->problems_by_index[DF_LIVE]) should ever be NULL?
cheers,
DaveK
--
Can't think of a witty .sigline today....
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Some regressions from the dataflow merge
2007-06-12 14:09 ` Richard Guenther
@ 2007-06-12 14:43 ` Kenneth Zadeck
2007-06-12 14:46 ` Richard Guenther
0 siblings, 1 reply; 16+ messages in thread
From: Kenneth Zadeck @ 2007-06-12 14:43 UTC (permalink / raw)
To: Richard Guenther; +Cc: gcc
Richard Guenther wrote:
> On Tue, 12 Jun 2007, Kenneth Zadeck wrote:
>
>
>> Richard Guenther wrote:
>>
>>> On ia64 SPEC2000 I see fma3d and applu now miscompare, and we have
>>> on x86_64 some performance regressions with Botan (a collection of
>>> cryptographic algorithms (see
>>> http://www.suse.de/~gcctest/c++bench/botan/)) - those are reasonably
>>> small enough to investigate, but wait another day in case its just noise.
>>>
>>> Otherwise things look smooth as expected.
>>>
>>> Richard.
>>>
>>>
>> I looked at the graphs here and i do not see a regression except in the
>> compile time.
>>
>
> Note the graphs are for Throughput, so higher numbers are better. Look
> for example at Serpent or Skipjack at
> http://www.suse.de/~gcctest/c++bench/botan/botan-summary.txt-1-0.html
> (which has separate graphs for each algorithm). But as I said - just
> wait a day to see if it is noise.
>
> Richard.
>
this is a different set of graphs than you sent the first time. now i
see the regressions.
i will add this to the growing set of things to look at.
kenny
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Some regressions from the dataflow merge
2007-06-12 14:43 ` Kenneth Zadeck
@ 2007-06-12 14:46 ` Richard Guenther
0 siblings, 0 replies; 16+ messages in thread
From: Richard Guenther @ 2007-06-12 14:46 UTC (permalink / raw)
To: Kenneth Zadeck; +Cc: gcc
On Tue, 12 Jun 2007, Kenneth Zadeck wrote:
> Richard Guenther wrote:
> > On Tue, 12 Jun 2007, Kenneth Zadeck wrote:
> >
> >
> >> Richard Guenther wrote:
> >>
> >>> On ia64 SPEC2000 I see fma3d and applu now miscompare, and we have
> >>> on x86_64 some performance regressions with Botan (a collection of
> >>> cryptographic algorithms (see
> >>> http://www.suse.de/~gcctest/c++bench/botan/)) - those are reasonably
> >>> small enough to investigate, but wait another day in case its just noise.
> >>>
> >>> Otherwise things look smooth as expected.
> >>>
> >>> Richard.
> >>>
> >>>
> >> I looked at the graphs here and i do not see a regression except in the
> >> compile time.
> >>
> >
> > Note the graphs are for Throughput, so higher numbers are better. Look
> > for example at Serpent or Skipjack at
> > http://www.suse.de/~gcctest/c++bench/botan/botan-summary.txt-1-0.html
> > (which has separate graphs for each algorithm). But as I said - just
> > wait a day to see if it is noise.
> >
> > Richard.
> >
> this is a different set of graphs than you sent the first time. now i
> see the regressions.
I just pointed you to the start page initially - clicking the graphs
will reveal these details.
Sorry for that,
Richard.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Some regressions from the dataflow merge
2007-06-12 14:35 ` Dave Korn
@ 2007-06-12 14:54 ` Kenneth Zadeck
2007-06-12 15:15 ` Dave Korn
0 siblings, 1 reply; 16+ messages in thread
From: Kenneth Zadeck @ 2007-06-12 14:54 UTC (permalink / raw)
To: Dave Korn; +Cc: 'Richard Guenther', gcc
Dave Korn wrote:
> On 12 June 2007 15:05, Kenneth Zadeck wrote:
>
>
>> Richard Guenther wrote:
>>
>>> On ia64 SPEC2000 I see fma3d and applu now miscompare, and we have
>>> on x86_64 some performance regressions with Botan (a collection of
>>> cryptographic algorithms (see
>>> http://www.suse.de/~gcctest/c++bench/botan/)) - those are reasonably small
>>> enough to investigate, but wait another day in case its just noise.
>>>
>>> Otherwise things look smooth as expected.
>>>
>>> Richard.
>>>
>>>
>> I looked at the graphs here and i do not see a regression except in the
>> compile time.
>>
>
> Fortran has a testcase that trips one on x86/cygwin: see
> http://gcc.gnu.org/ml/gcc/2007-06/msg00291.html. Perhaps you can comment on
> whether df_live (== df->problems_by_index[DF_LIVE]) should ever be NULL?
>
>
> cheers,
> DaveK
>
From what i can gather from looking at the "stacktrace", the problem is that
ix86_eax_live_at_start_p is only called on cigwin and of course we did
not check cigwin.
This is an easy fix.
Change the macro "DF_LIVE_OUT" in this function to the function call
"df_get_live_out". It takes the same parameter and returns the same thing.
I believe this will fix the problem.
kenny
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: Some regressions from the dataflow merge
2007-06-12 14:54 ` Kenneth Zadeck
@ 2007-06-12 15:15 ` Dave Korn
0 siblings, 0 replies; 16+ messages in thread
From: Dave Korn @ 2007-06-12 15:15 UTC (permalink / raw)
To: 'Kenneth Zadeck'
Cc: 'Richard Guenther', gcc, 'Fortran List'
On 12 June 2007 15:55, Kenneth Zadeck wrote:
> Dave Korn wrote:
>> On 12 June 2007 15:05, Kenneth Zadeck wrote:
>>> Richard Guenther wrote:
>>>
>>>> On ia64 SPEC2000 I see fma3d and applu now miscompare, and we have
>>>> on x86_64 some performance regressions with Botan (a collection of
>>>> cryptographic algorithms (see
>>>> http://www.suse.de/~gcctest/c++bench/botan/)) - those are reasonably
>>>> small enough to investigate, but wait another day in case its just
>>>> noise.
>>>>
>>>> Otherwise things look smooth as expected.
>>>>
>>>> Richard.
>>> I looked at the graphs here and i do not see a regression except in the
>>> compile time.
>> Fortran has a testcase that trips one on x86/cygwin: see
>> http://gcc.gnu.org/ml/gcc/2007-06/msg00291.html. Perhaps you can comment
>> on whether df_live (== df->problems_by_index[DF_LIVE]) should ever be
>> NULL?
> From what i can gather from looking at the "stacktrace", the problem is that
> ix86_eax_live_at_start_p is only called on cigwin and of course we did
> not check cigwin.
>
> This is an easy fix.
>
> Change the macro "DF_LIVE_OUT" in this function to the function call
> "df_get_live_out". It takes the same parameter and returns the same thing.
>
> I believe this will fix the problem.
Thanks for the advice Kenny. CC'ing the Fortran list because I don't have
time to put into this right away: Paul or FX, perhaps you'd like to give that
advice a try?
cheers,
DaveK
--
Can't think of a witty .sigline today....
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Some regressions from the dataflow merge
2007-06-12 11:48 Some regressions from the dataflow merge Richard Guenther
2007-06-12 14:05 ` Kenneth Zadeck
@ 2007-06-12 19:10 ` Richard Guenther
2007-06-12 20:41 ` Seongbae Park (박성배, 朴成培)
2007-06-13 19:22 ` Kenneth Zadeck
1 sibling, 2 replies; 16+ messages in thread
From: Richard Guenther @ 2007-06-12 19:10 UTC (permalink / raw)
To: gcc; +Cc: zadeck
On Tue, 12 Jun 2007, Richard Guenther wrote:
>
> On ia64 SPEC2000 I see fma3d and applu now miscompare.
On x86_64 186.wupwise ICEs with -O2 -ffast-math and FDO:
/gcc/spec/sb-haydn-fdo-64/x86_64/install-200706120559/bin/gfortran -c -o
zscal.o -fprofile-use -O2 -ffast-math zscal.f
Error from fdo_make_pass2 'specmake -j2 FDO=PASS2 build 2>
fdo_make_pass2.err | tee fdo_make_pass2.out':
zgemm.f: In function 'zgemm':
zgemm.f:413: internal compiler error: in remove_insn, at emit-rtl.c:3597
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
Likewise for 176.gcc:
combine.c: In function 'simplify_comparison':
combine.c:9697: internal compiler error: in remove_insn, at
emit-rtl.c:3597
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
specmake: *** [combine.o] Error 1
Richard.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Some regressions from the dataflow merge
2007-06-12 19:10 ` Richard Guenther
@ 2007-06-12 20:41 ` Seongbae Park (박성배, 朴成培)
2007-06-12 20:45 ` Kenneth Zadeck
2007-06-13 19:22 ` Kenneth Zadeck
1 sibling, 1 reply; 16+ messages in thread
From: Seongbae Park (박성배, 朴成培) @ 2007-06-12 20:41 UTC (permalink / raw)
To: Richard Guenther; +Cc: gcc, zadeck
On 6/12/07, Richard Guenther <rguenther@suse.de> wrote:
> On Tue, 12 Jun 2007, Richard Guenther wrote:
>
> >
> > On ia64 SPEC2000 I see fma3d and applu now miscompare.
>
> On x86_64 186.wupwise ICEs with -O2 -ffast-math and FDO:
>
> /gcc/spec/sb-haydn-fdo-64/x86_64/install-200706120559/bin/gfortran -c -o
> zscal.o -fprofile-use -O2 -ffast-math zscal.f
> Error from fdo_make_pass2 'specmake -j2 FDO=PASS2 build 2>
> fdo_make_pass2.err | tee fdo_make_pass2.out':
> zgemm.f: In function 'zgemm':
> zgemm.f:413: internal compiler error: in remove_insn, at emit-rtl.c:3597
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
>
> Likewise for 176.gcc:
>
> combine.c: In function 'simplify_comparison':
> combine.c:9697: internal compiler error: in remove_insn, at
> emit-rtl.c:3597
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> specmake: *** [combine.o] Error 1
Sounds like there's a pass that are emitting a barrier during cfglayout mode.
I'll look at them.
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com"
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Some regressions from the dataflow merge
2007-06-12 20:41 ` Seongbae Park (박성배, 朴成培)
@ 2007-06-12 20:45 ` Kenneth Zadeck
0 siblings, 0 replies; 16+ messages in thread
From: Kenneth Zadeck @ 2007-06-12 20:45 UTC (permalink / raw)
To: "Seongbae Park (???, ???)"; +Cc: Richard Guenther, gcc
Seongbae Park (???, ???) wrote:
> On 6/12/07, Richard Guenther <rguenther@suse.de> wrote:
>> On Tue, 12 Jun 2007, Richard Guenther wrote:
>>
>> >
>> > On ia64 SPEC2000 I see fma3d and applu now miscompare.
>>
>> On x86_64 186.wupwise ICEs with -O2 -ffast-math and FDO:
>>
>> /gcc/spec/sb-haydn-fdo-64/x86_64/install-200706120559/bin/gfortran -c -o
>> zscal.o -fprofile-use -O2 -ffast-math zscal.f
>> Error from fdo_make_pass2 'specmake -j2 FDO=PASS2 build 2>
>> fdo_make_pass2.err | tee fdo_make_pass2.out':
>> zgemm.f: In function 'zgemm':
>> zgemm.f:413: internal compiler error: in remove_insn, at emit-rtl.c:3597
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
>>
>> Likewise for 176.gcc:
>>
>> combine.c: In function 'simplify_comparison':
>> combine.c:9697: internal compiler error: in remove_insn, at
>> emit-rtl.c:3597
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
>> specmake: *** [combine.o] Error 1
>
> Sounds like there's a pass that are emitting a barrier during
> cfglayout mode.
> I'll look at them.
see if danny accidently reverted your gcse fix for this
kenny
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Some regressions from the dataflow merge
2007-06-12 19:10 ` Richard Guenther
2007-06-12 20:41 ` Seongbae Park (박성배, 朴成培)
@ 2007-06-13 19:22 ` Kenneth Zadeck
2007-06-13 21:39 ` Richard Guenther
2007-06-14 8:09 ` Richard Guenther
1 sibling, 2 replies; 16+ messages in thread
From: Kenneth Zadeck @ 2007-06-13 19:22 UTC (permalink / raw)
To: Richard Guenther; +Cc: gcc
Richard Guenther wrote:
> On Tue, 12 Jun 2007, Richard Guenther wrote:
>
>
>> On ia64 SPEC2000 I see fma3d and applu now miscompare.
>>
>
> On x86_64 186.wupwise ICEs with -O2 -ffast-math and FDO:
>
> /gcc/spec/sb-haydn-fdo-64/x86_64/install-200706120559/bin/gfortran -c -o
> zscal.o -fprofile-use -O2 -ffast-math zscal.f
> Error from fdo_make_pass2 'specmake -j2 FDO=PASS2 build 2>
> fdo_make_pass2.err | tee fdo_make_pass2.out':
> zgemm.f: In function 'zgemm':
> zgemm.f:413: internal compiler error: in remove_insn, at emit-rtl.c:3597
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
>
> Likewise for 176.gcc:
>
> combine.c: In function 'simplify_comparison':
> combine.c:9697: internal compiler error: in remove_insn, at
> emit-rtl.c:3597
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> specmake: *** [combine.o] Error 1
>
> Richard.
>
Richard,
did these two regression go away? We committed a change to gcse that
should have fixed this bug.
kenny
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Some regressions from the dataflow merge
2007-06-13 19:22 ` Kenneth Zadeck
@ 2007-06-13 21:39 ` Richard Guenther
2007-06-14 8:09 ` Richard Guenther
1 sibling, 0 replies; 16+ messages in thread
From: Richard Guenther @ 2007-06-13 21:39 UTC (permalink / raw)
To: Kenneth Zadeck; +Cc: Richard Guenther, gcc
On 6/13/07, Kenneth Zadeck <zadeck@naturalbridge.com> wrote:
> Richard Guenther wrote:
> > On Tue, 12 Jun 2007, Richard Guenther wrote:
> >
> >
> >> On ia64 SPEC2000 I see fma3d and applu now miscompare.
> >>
> >
> > On x86_64 186.wupwise ICEs with -O2 -ffast-math and FDO:
> >
> > /gcc/spec/sb-haydn-fdo-64/x86_64/install-200706120559/bin/gfortran -c -o
> > zscal.o -fprofile-use -O2 -ffast-math zscal.f
> > Error from fdo_make_pass2 'specmake -j2 FDO=PASS2 build 2>
> > fdo_make_pass2.err | tee fdo_make_pass2.out':
> > zgemm.f: In function 'zgemm':
> > zgemm.f:413: internal compiler error: in remove_insn, at emit-rtl.c:3597
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> >
> > Likewise for 176.gcc:
> >
> > combine.c: In function 'simplify_comparison':
> > combine.c:9697: internal compiler error: in remove_insn, at
> > emit-rtl.c:3597
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> > specmake: *** [combine.o] Error 1
> >
> > Richard.
> >
> Richard,
>
> did these two regression go away? We committed a change to gcse that
> should have fixed this bug.
Sorry, we have to wait another day - the placement new patch caused
conflicts on svn update on the tree (DAMN IDENTICAL LOCAL FILES
CONFLICTS - svn sucks). I'll keep you posted if they still fail after
the gcse patch.
Richard.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Some regressions from the dataflow merge
2007-06-13 19:22 ` Kenneth Zadeck
2007-06-13 21:39 ` Richard Guenther
@ 2007-06-14 8:09 ` Richard Guenther
2007-06-14 14:37 ` Seongbae Park (박성배, 朴成培)
1 sibling, 1 reply; 16+ messages in thread
From: Richard Guenther @ 2007-06-14 8:09 UTC (permalink / raw)
To: Kenneth Zadeck; +Cc: gcc
On Wed, 13 Jun 2007, Kenneth Zadeck wrote:
> Richard Guenther wrote:
> > On Tue, 12 Jun 2007, Richard Guenther wrote:
> >
> >
> >> On ia64 SPEC2000 I see fma3d and applu now miscompare.
> >>
> >
> > On x86_64 186.wupwise ICEs with -O2 -ffast-math and FDO:
> >
> > /gcc/spec/sb-haydn-fdo-64/x86_64/install-200706120559/bin/gfortran -c -o
> > zscal.o -fprofile-use -O2 -ffast-math zscal.f
> > Error from fdo_make_pass2 'specmake -j2 FDO=PASS2 build 2>
> > fdo_make_pass2.err | tee fdo_make_pass2.out':
> > zgemm.f: In function 'zgemm':
> > zgemm.f:413: internal compiler error: in remove_insn, at emit-rtl.c:3597
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> >
> > Likewise for 176.gcc:
> >
> > combine.c: In function 'simplify_comparison':
> > combine.c:9697: internal compiler error: in remove_insn, at
> > emit-rtl.c:3597
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> > specmake: *** [combine.o] Error 1
> >
> > Richard.
> >
> Richard,
>
> did these two regression go away? We committed a change to gcse that
> should have fixed this bug.
These two are gone now. The ia64 miscompares still are there.
Richard.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Some regressions from the dataflow merge
2007-06-14 8:09 ` Richard Guenther
@ 2007-06-14 14:37 ` Seongbae Park (박성배, 朴成培)
2007-06-15 8:12 ` Maxim Kuvyrkov
0 siblings, 1 reply; 16+ messages in thread
From: Seongbae Park (박성배, 朴成培) @ 2007-06-14 14:37 UTC (permalink / raw)
To: Richard Guenther; +Cc: Kenneth Zadeck, gcc
On 6/14/07, Richard Guenther <rguenther@suse.de> wrote:
> On Wed, 13 Jun 2007, Kenneth Zadeck wrote:
>
> > Richard Guenther wrote:
> > > On Tue, 12 Jun 2007, Richard Guenther wrote:
> > >
> > >
> > >> On ia64 SPEC2000 I see fma3d and applu now miscompare.
> > >>
> > >
> > > On x86_64 186.wupwise ICEs with -O2 -ffast-math and FDO:
> > >
> > > /gcc/spec/sb-haydn-fdo-64/x86_64/install-200706120559/bin/gfortran -c -o
> > > zscal.o -fprofile-use -O2 -ffast-math zscal.f
> > > Error from fdo_make_pass2 'specmake -j2 FDO=PASS2 build 2>
> > > fdo_make_pass2.err | tee fdo_make_pass2.out':
> > > zgemm.f: In function 'zgemm':
> > > zgemm.f:413: internal compiler error: in remove_insn, at emit-rtl.c:3597
> > > Please submit a full bug report,
> > > with preprocessed source if appropriate.
> > > See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> > >
> > > Likewise for 176.gcc:
> > >
> > > combine.c: In function 'simplify_comparison':
> > > combine.c:9697: internal compiler error: in remove_insn, at
> > > emit-rtl.c:3597
> > > Please submit a full bug report,
> > > with preprocessed source if appropriate.
> > > See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> > > specmake: *** [combine.o] Error 1
> > >
> > > Richard.
> > >
> > Richard,
> >
> > did these two regression go away? We committed a change to gcse that
> > should have fixed this bug.
>
> These two are gone now. The ia64 miscompares still are there.
I'm looking at it. It is either a scheduler problem,
or some other problem downstream triggered by the scheduler.
However, I'm having hard time adding fine-grained dbg_cnt to our scheduler
- do you know who might be interested in adding insn level
dbg_cnt in the scheduler ? Current dbg_cnt (sched_insn) causes ICE :(
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com"
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Some regressions from the dataflow merge
2007-06-14 14:37 ` Seongbae Park (박성배, 朴成培)
@ 2007-06-15 8:12 ` Maxim Kuvyrkov
0 siblings, 0 replies; 16+ messages in thread
From: Maxim Kuvyrkov @ 2007-06-15 8:12 UTC (permalink / raw)
To: "Seongbae Park (???, ???)"; +Cc: Richard Guenther, Kenneth Zadeck, gcc
[-- Attachment #1: Type: text/plain, Size: 933 bytes --]
Seongbae Park (???, ???) wrote:
...
> I'm looking at it. It is either a scheduler problem,
> or some other problem downstream triggered by the scheduler.
> However, I'm having hard time adding fine-grained dbg_cnt to our scheduler
> - do you know who might be interested in adding insn level
> dbg_cnt in the scheduler ? Current dbg_cnt (sched_insn) causes ICE :(
IMHO, the least intrusive way of using a debug counter in scheduler is
to place into instruction choosing module and make scheduler to chose
next instruction at all times. I have successfully used this technique
in debugging selective scheduler and believe it will suit haifa
scheduler perfectly.
I've attached a patch that moves dbg_cnt to choose_ready () routine, but
at this point have no time to test it for usability (though it compiles
fine on x86_64). If the patch won't work please let me know and I'll
fix it during the weekend.
Regards,
Maxim
[-- Attachment #2: sched-dbg-cnt.patch --]
[-- Type: text/x-patch, Size: 4133 bytes --]
Index: haifa-sched.c
===================================================================
--- haifa-sched.c (revision 125737)
+++ haifa-sched.c (working copy)
@@ -539,7 +539,7 @@ static rtx ready_remove (struct ready_li
static void ready_remove_insn (rtx);
static int max_issue (struct ready_list *, int *, int);
-static rtx choose_ready (struct ready_list *);
+static int choose_ready (struct ready_list *, rtx *);
static void fix_inter_tick (rtx, rtx);
static int fix_tick_ready (rtx);
@@ -1980,17 +1980,42 @@ max_issue (struct ready_list *ready, int
/* The following function chooses insn from READY and modifies
*N_READY and READY. The following function is used only for first
- cycle multipass scheduling. */
-
-static rtx
-choose_ready (struct ready_list *ready)
+ cycle multipass scheduling.
+ Return:
+ -1 if cycle should be advanced,
+ 0 if INSN_PTR is set to point to the desirable insn,
+ 1 if choose_ready () should be restarted without advancing the cycle. */
+static int
+choose_ready (struct ready_list *ready, rtx *insn_ptr)
{
- int lookahead = 0;
+ int lookahead;
+
+ if (dbg_cnt (sched_insn) == false)
+ {
+ rtx insn;
+
+ insn = NEXT_INSN (last_scheduled_insn);
+
+ if (QUEUE_INDEX (insn) == QUEUE_READY)
+ /* INSN is in the ready_list. */
+ {
+ *insn_ptr = insn;
+ return 0;
+ }
+
+ /* INSN is in the queue. Advance cycle to move it to the ready list. */
+ return -1;
+ }
+
+ lookahead = 0;
if (targetm.sched.first_cycle_multipass_dfa_lookahead)
lookahead = targetm.sched.first_cycle_multipass_dfa_lookahead ();
if (lookahead <= 0 || SCHED_GROUP_P (ready_element (ready, 0)))
- return ready_remove_first (ready);
+ {
+ *insn_ptr = ready_remove_first (ready);
+ return 0;
+ }
else
{
/* Try to choose the better insn. */
@@ -2007,7 +2032,10 @@ choose_ready (struct ready_list *ready)
}
insn = ready_element (ready, 0);
if (INSN_CODE (insn) < 0)
- return ready_remove_first (ready);
+ {
+ *insn_ptr = ready_remove_first (ready);
+ return 0;
+ }
if (spec_info
&& spec_info->flags & (PREFER_NON_DATA_SPEC
@@ -2049,7 +2077,7 @@ choose_ready (struct ready_list *ready)
list. */
{
change_queue_index (insn, 1);
- return 0;
+ return 1;
}
max_points = ISSUE_POINTS (insn);
@@ -2071,9 +2099,15 @@ choose_ready (struct ready_list *ready)
}
if (max_issue (ready, &index, max_points) == 0)
- return ready_remove_first (ready);
+ {
+ *insn_ptr = ready_remove_first (ready);
+ return 0;
+ }
else
- return ready_remove (ready, index);
+ {
+ *insn_ptr = ready_remove (ready, index);
+ return 0;
+ }
}
}
@@ -2271,29 +2305,22 @@ schedule_block (basic_block *target_bb,
|| !(*current_sched_info->schedule_more_p) ())
break;
- if (dbg_cnt (sched_insn) == false)
- {
- insn = NEXT_INSN (last_scheduled_insn);
- while ((*current_sched_info->schedule_more_p) ())
- {
- (*current_sched_info->begin_schedule_ready) (insn,
- last_scheduled_insn);
- if (QUEUE_INDEX (insn) >= 0)
- queue_remove (insn);
- last_scheduled_insn = insn;
- insn = NEXT_INSN (insn);
- }
- while (ready.n_ready)
- ready_remove_first (&ready);
- goto bail_out;
- }
-
/* Select and remove the insn from the ready list. */
if (sort_p)
{
- insn = choose_ready (&ready);
- if (!insn)
+ int res;
+
+ insn = NULL_RTX;
+ res = choose_ready (&ready, &insn);
+
+ if (res < 0)
+ /* Finish cycle. */
+ break;
+ if (res > 0)
+ /* Restart choose_ready (). */
continue;
+
+ gcc_assert (insn != NULL_RTX);
}
else
insn = ready_remove_first (&ready);
@@ -2445,7 +2472,6 @@ schedule_block (basic_block *target_bb,
}
}
-bail_out:
/* Debug info. */
if (sched_verbose)
{
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2007-06-15 8:12 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-06-12 11:48 Some regressions from the dataflow merge Richard Guenther
2007-06-12 14:05 ` Kenneth Zadeck
2007-06-12 14:09 ` Richard Guenther
2007-06-12 14:43 ` Kenneth Zadeck
2007-06-12 14:46 ` Richard Guenther
2007-06-12 14:35 ` Dave Korn
2007-06-12 14:54 ` Kenneth Zadeck
2007-06-12 15:15 ` Dave Korn
2007-06-12 19:10 ` Richard Guenther
2007-06-12 20:41 ` Seongbae Park (박성배, 朴成培)
2007-06-12 20:45 ` Kenneth Zadeck
2007-06-13 19:22 ` Kenneth Zadeck
2007-06-13 21:39 ` Richard Guenther
2007-06-14 8:09 ` Richard Guenther
2007-06-14 14:37 ` Seongbae Park (박성배, 朴成培)
2007-06-15 8:12 ` Maxim Kuvyrkov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).