Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch
H. J. Lu wrote: We are working on complete data of SPEC CPU 2K/2006 on Core 2 Duo. It will take about a week. There are results' comparison I got for gcc 4.2 revisions 117890, 117891 and 121952 on SPEC CPU2K/2006 SPEC CPU2000: 117891 vs 117890 121952 vs 117890 164.gzip-0.1%0.0% 175.vpr -0.1%0.8% 176.gcc -0.1% -0.3% 181.mcf -0.4% -1.3% 186.crafty -0.8% -0.8% 197.parser -0.2% -0.1% 252.eon 0.5%0.2% 253.perlbmk -0.8%0.1% 254.gap -2.5% -0.7% 255.vortex -0.6% -0.2% 256.bzip2 -1.1%0.1% 300.twolf -0.5%0.0% SPECint_base2000-0.5% -0.2% 168.wupwise 0.0% -0.6% 171.swim 0.8%0.8% 172.mgrid0.0% -0.1% 173.applu0.5%2.6% 177.mesa-0.4%0.0% 178.galgel 0.0% -0.1% 179.art -0.4%0.1% 183.equake 0.0% -0.2% 187.facerec -0.1%0.1% 188.ammp 0.1%0.1% 189.lucas0.0%0.0% 191.fma3d -1.3% -2.3% 200.sixtrack-0.1%0.2% 301.apsi 0.1%0.3% SPECfp_base2000 -0.1%0.1% SPEC CPU2006 117891 vs 117890 121952 vs 117890 400.perlbench0.0% -0.6% 401.bzip20.7%0.0% 403.gcc 0.9%0.9% 429.mcf -0.7%0.0% 445.gobmk1.4%0.7% 456.hmmer1.0%1.0% 458.sjeng -1.4% -0.7% 462.libquantum -1.6%0.0% 464.h264ref -0.5%0.5% 471.omnetpp 0.9%0.9% 473.astar0.0% -1.0% 483.xalancbmk -0.1%0.4% SPECint_base2006 0.0%0.8% 410.bwaves 0.5%0.4% 416.gamess 0.0% -0.8% 433.milc 0.0%0.0% 434.zeusmp 0.0%0.0% 435.gromacs 0.1%0.0% 436.cactusADM -0.1% -0.1% 437.leslie3d -30.1% -30.3% 444.namd 0.0%0.0% 447.dealII 0.0% -1.4% 450.soplex 0.0%0.7% 453.povray -0.6% -2.5% 454.calculix 0.0% -0.4% 459.GemsFDTD -18.6% -18.7% 465.tonto -1.8% -0.9% 470.lbm 0.0%0.0% 481.wrf -0.6% -0.3% 482.sphinx3 0.0%0.0% SPECfp_base2006 -3.5% -3.5% Denis
Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch
Mark Mitchell wrote: Vladimir Makarov wrote: I remember nocona tunning gave 30% improvement SPECFp2000 for Intel nocona in 64 bit mode in comparison with the default x86_64 gcc tuning (for k8). So such big improvement is definetly mostly from new -mtune=generic. Well, then, lets get numbers for other targets! I'd love to see the same data for PowerPC, MIPS, etc. This discussion will be much more productive in the presence of data. There are no absolutes: it's not "we can't ship with bugs", "we can't ship with performance regressions", etc. We've got to balance quality on various axes, and to do that we need to know the numbers. I'd put Amd x86_64 first beacuse x86_64 gcc4.1 was tuned for this processor. Unfortunately, I have no available Amd machine for SPEC and can not help. Sorry.
Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch
Vladimir Makarov wrote: > I remember nocona tunning gave 30% improvement SPECFp2000 for Intel > nocona in 64 bit mode in comparison with the default x86_64 gcc tuning > (for k8). So such big improvement is definetly mostly from new > -mtune=generic. Well, then, lets get numbers for other targets! I'd love to see the same data for PowerPC, MIPS, etc. This discussion will be much more productive in the presence of data. There are no absolutes: it's not "we can't ship with bugs", "we can't ship with performance regressions", etc. We've got to balance quality on various axes, and to do that we need to know the numbers. Also, it's FSF compilers I'm concerned about, not distribution compilers. After all, we're talking about FSF releases. Many people use FSF releases directly, or indirectly via distributions (GNU/Linux and otherwise) other than Red Hat and Novell. It's true that Red Hat and Novell put various things into their 4.1 compilers (like -mtune=generic) that are a win; that's part of their value-add. However, they can similarly modify 4.2 compilers (if they ship them) by, for example, trading potential aliasing bugs for performance, if that seems like a win. It doesn't make sense to compare unmodified FSF 4.2 compilers with distribution-optimized 4.1 compilers. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch
Jan Hubicka wrote: Grigory Zagorodnev wrote: Mark Mitchell wrote: Excellent question; I should have asked for that as well. If 4.2 has gained on 4.1 in other respects, the 4.7% drop might represent a smaller regression relative to 4.1. There is the 4.2 (r120817) vs. 4.1.2 release FP performance comparison numbers. SPECfp_base2006 of gcc 4.2 has 19% performance gain over 4.1.2. Thank you for the measurements. In that case, I think we have absolutely nothing to worry about for 4.2.0. Whether we deliver 19% SPECfp, 23% SPECfp, or 15% SPECfp improvements isn't so important; all of those numbers are a vast improvement over 4.1.x. Given that, I think we should just leave Danny's conservative changes in, and not worry. It should be understood that the large improvement on Cores is special case caused by adding a generic model and CPU specific tuning (We originally measured 28% speedup on P4 and SPECfp2000 just for that change). Situation can be less optimistic on other (sub)targets. Still we made important progress on SPECfp in the 4.x series, so 4% slowdown would not bring us to performance of GCC's from mid 90's as 4% slowdown on SPECint would perhaps do... I remember nocona tunning gave 30% improvement SPECFp2000 for Intel nocona in 64 bit mode in comparison with the default x86_64 gcc tuning (for k8). So such big improvement is definetly mostly from new -mtune=generic.
Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch
> Grigory Zagorodnev wrote: > > Mark Mitchell wrote: > >> Excellent question; I should have asked for that as well. If 4.2 has > >> gained on 4.1 in other respects, the 4.7% drop might represent a smaller > >> regression relative to 4.1. > >> > > There is the 4.2 (r120817) vs. 4.1.2 release FP performance comparison > > numbers. SPECfp_base2006 of gcc 4.2 has 19% performance gain over 4.1.2. > > Thank you for the measurements. > > In that case, I think we have absolutely nothing to worry about for > 4.2.0. Whether we deliver 19% SPECfp, 23% SPECfp, or 15% SPECfp > improvements isn't so important; all of those numbers are a vast > improvement over 4.1.x. Given that, I think we should just leave > Danny's conservative changes in, and not worry. It should be understood that the large improvement on Cores is special case caused by adding a generic model and CPU specific tuning (We originally measured 28% speedup on P4 and SPECfp2000 just for that change). Situation can be less optimistic on other (sub)targets. Still we made important progress on SPECfp in the 4.x series, so 4% slowdown would not bring us to performance of GCC's from mid 90's as 4% slowdown on SPECint would perhaps do... Honza > > Thanks, > > -- > Mark Mitchell > CodeSourcery > [EMAIL PROTECTED] > (650) 331-3385 x713
Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch
Grigory Zagorodnev wrote: > Mark Mitchell wrote: >> Excellent question; I should have asked for that as well. If 4.2 has >> gained on 4.1 in other respects, the 4.7% drop might represent a smaller >> regression relative to 4.1. >> > There is the 4.2 (r120817) vs. 4.1.2 release FP performance comparison > numbers. SPECfp_base2006 of gcc 4.2 has 19% performance gain over 4.1.2. Thank you for the measurements. In that case, I think we have absolutely nothing to worry about for 4.2.0. Whether we deliver 19% SPECfp, 23% SPECfp, or 15% SPECfp improvements isn't so important; all of those numbers are a vast improvement over 4.1.x. Given that, I think we should just leave Danny's conservative changes in, and not worry. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch
Mark Mitchell wrote: Excellent question; I should have asked for that as well. If 4.2 has gained on 4.1 in other respects, the 4.7% drop might represent a smaller regression relative to 4.1. There is the 4.2 (r120817) vs. 4.1.2 release FP performance comparison numbers. SPECfp_base2006 of gcc 4.2 has 19% performance gain over 4.1.2. 410.bwaves 1.9% 416.gamess 55.0% 433.milc3.6% 434.zeusmp 39.8% 435.gromacs 0.6% 436.cactusADM 33.3% 437.leslie3d-6.9% 444.namd80.1% 447.dealII 13.5% 450.soplex 0.8% 453.povray 14.4% 454.calculix182.4% 459.GemsFDTD-8.3% 465.tonto 21.5% 470.lbm -4.6% 481.wrf -6.4% 482.sphinx3 0.0% SPECfp_base2006 18.8% - Grigory
Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch
On Tue, Feb 20, 2007 at 03:53:55PM -0800, Mark Mitchell wrote: > Richard Guenther wrote: > > >> This is 4.7% drop of SPECfp_base2006 ratio (geomean of individual FP > >> ratios). > > Clearly, 4.7% is significant. Grigory, thanks for the measurements! > > >> Here is the full set of changes in cpu2k6/fp performance of GCC 4.2 > >> compiler between r116799 and r120817, measured on Intel Core2 Duo at -O2 > >> optimization level. > > > > Do you happen to have a 4.1.x baseline to compare those against? > > Excellent question; I should have asked for that as well. If 4.2 has > gained on 4.1 in other respects, the 4.7% drop might represent a smaller > regression relative to 4.1. > Comparing gcc 4.1 performance on 64bit Intel against 4.2 isn't very meaningful since the -mtune=generic patch isn't in gcc 4.1. However, gcc 4.1 from many Linux vendors do include it. I suggest we do one or all of the followings: 1. Limit gcc 4.1 on 32bit. 2. Limit gcc 4.1 on non-Intel platforms. 3. Use of one of gcc 4.1 from Linux vendor as a reference. gcc 4.1 from Red Hat and Novell are OK. H.J.
Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch
Richard Guenther wrote: >> This is 4.7% drop of SPECfp_base2006 ratio (geomean of individual FP >> ratios). Clearly, 4.7% is significant. Grigory, thanks for the measurements! >> Here is the full set of changes in cpu2k6/fp performance of GCC 4.2 >> compiler between r116799 and r120817, measured on Intel Core2 Duo at -O2 >> optimization level. > > Do you happen to have a 4.1.x baseline to compare those against? Excellent question; I should have asked for that as well. If 4.2 has gained on 4.1 in other respects, the 4.7% drop might represent a smaller regression relative to 4.1. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch
On 2/20/07, Grigory Zagorodnev <[EMAIL PROTECTED]> wrote: Mark Mitchell wrote: >> FP performance regressions of the recent GCC 4.2 (revision 120817) >> compiler against September GCC 4.2 (revision 116799) > What does that translate to in terms of overall score? > Hi, This is 4.7% drop of SPECfp_base2006 ratio (geomean of individual FP ratios). Here is the full set of changes in cpu2k6/fp performance of GCC 4.2 compiler between r116799 and r120817, measured on Intel Core2 Duo at -O2 optimization level. Do you happen to have a 4.1.x baseline to compare those against? Richard. 410.bwaves -6.3% 416.gamess -0.7% 433.milc-7.0% 434.zeusmp 0.0% 435.gromacs -0.4% 436.cactusADM -1.1% 437.leslie3d-25.4% 444.namd0.0% 447.dealII -1.4% 450.soplex -3.9% 453.povray 0.0% 454.calculix-0.3% 459.GemsFDTD-18.3% 465.tonto -2.5% 470.lbm -4.1% 481.wrf -2.7% 482.sphinx3 -1.2% SPECfp_base2006 -4.7% - Grigory
Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch
Mark Mitchell wrote: FP performance regressions of the recent GCC 4.2 (revision 120817) compiler against September GCC 4.2 (revision 116799) What does that translate to in terms of overall score? Hi, This is 4.7% drop of SPECfp_base2006 ratio (geomean of individual FP ratios). Here is the full set of changes in cpu2k6/fp performance of GCC 4.2 compiler between r116799 and r120817, measured on Intel Core2 Duo at -O2 optimization level. 410.bwaves -6.3% 416.gamess -0.7% 433.milc-7.0% 434.zeusmp 0.0% 435.gromacs -0.4% 436.cactusADM -1.1% 437.leslie3d-25.4% 444.namd0.0% 447.dealII -1.4% 450.soplex -3.9% 453.povray 0.0% 454.calculix-0.3% 459.GemsFDTD-18.3% 465.tonto -2.5% 470.lbm -4.1% 481.wrf -2.7% 482.sphinx3 -1.2% SPECfp_base2006 -4.7% - Grigory
Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch
On 2/19/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: Daniel Berlin wrote: >> 2. What is the effort required to backport the necessary infrastructure >> from 4.3? I'm not looking for "a lot" or "is hard", but rather, "two >> weeks" or "six months". What needs to be backported, and what are the >> challenges? > > Including bug fixes, i'd guess 2 months to be conservative. OK, thanks. That seems like a lot of effort; certainly more than I could try to browbeat you into doing. :-) A lot of this is also that we are still shaking out performance regressions that are a combination of fixes and changes for mem-ssa. We'd still have to do that if we backported the 4.3 changes. There are less of them, for sure, than there are in 4.2, but they are still there. > There are no real challenges other than applying the patches and doing > a lot of testing, since most of these patches were written pretty > early on during the 4.3 cycle. Is there anyone brave enough to volunteer to try? If this were to turn out to be substantially easier than Danny thinks, then it sounds like it might be a good solution. However, there's no reason to expect that, and I think two person-months is rather much. If things go perfect, it would take probably 2 weeks. We could start by reverting the patch and applying the fixes until you are happy, if that would be better? If you stopped before the end you will end up with the freefem3d memory regression, but nothing more. Therefore, it sounds like the practical choices are revert the patch and accept the bugs, or vice versa. Is there any reason to expect the bugs to be particularly more prevalent in 4.2 than they were in 4.1? Nope.
Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch
Daniel Berlin wrote: >> 2. What is the effort required to backport the necessary infrastructure >> from 4.3? I'm not looking for "a lot" or "is hard", but rather, "two >> weeks" or "six months". What needs to be backported, and what are the >> challenges? > > Including bug fixes, i'd guess 2 months to be conservative. OK, thanks. That seems like a lot of effort; certainly more than I could try to browbeat you into doing. :-) > There are no real challenges other than applying the patches and doing > a lot of testing, since most of these patches were written pretty > early on during the 4.3 cycle. Is there anyone brave enough to volunteer to try? If this were to turn out to be substantially easier than Danny thinks, then it sounds like it might be a good solution. However, there's no reason to expect that, and I think two person-months is rather much. Therefore, it sounds like the practical choices are revert the patch and accept the bugs, or vice versa. Is there any reason to expect the bugs to be particularly more prevalent in 4.2 than they were in 4.1? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch
H. J. Lu wrote: > FP performance regressions of the recent GCC 4.2 (revision 120817) > compiler against September GCC 4.2 (revision 116799) > 410.bwaves -6.3% > 433.milc-7.0% > 437.leslie3d-25.4% > 450.soplex -3.9% > 459.GemsFDTD-18.3% > 465.tonto -2.5% > 470.lbm -4.1% > 481.wrf -2.7% What does that translate to in terms of overall score? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch
On Mon, Feb 19, 2007 at 03:16:12PM -0800, Mark Mitchell wrote: > Daniel Berlin wrote: > > >> > > > It looks like your changeset listed bellow makes performance > >> > > > regression ~40% on SPEC2006/leslie3d. I will try to create minimal > >> > > > test for this issue this week and update you in any case. > > >> > The price of fixing them in 4.2 was a serious performance drop. > >> > >> There's the option of un-fixing them to get back to the state of 4.1 > >> declaring > >> them fixed in 4.3 earliest. > > I would like to understand a few things: > > 1. What is the overall drop in SPEC scores as a result of this patch? I > understand the impact on leslie3d, but what is the overall impact? > Hopefully, this is an easy question to answer: run SPEC, revert the > patch, run SPEC again. > We are working on complete data of SPEC CPU 2K/2006 on Core 2 Duo. It will take about a week. Our earlier, mid Jan., SPEC CPU 2006 shows: FP performance regressions of the recent GCC 4.2 (revision 120817) compiler against September GCC 4.2 (revision 116799) 410.bwaves -6.3% 433.milc-7.0% 437.leslie3d-25.4% 450.soplex -3.9% 459.GemsFDTD-18.3% 465.tonto -2.5% 470.lbm -4.1% 481.wrf -2.7% H.J.
Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch
On 2/19/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: Daniel Berlin wrote: >> > > > It looks like your changeset listed bellow makes performance >> > > > regression ~40% on SPEC2006/leslie3d. I will try to create minimal >> > > > test for this issue this week and update you in any case. >> > The price of fixing them in 4.2 was a serious performance drop. >> >> There's the option of un-fixing them to get back to the state of 4.1 >> declaring >> them fixed in 4.3 earliest. I would like to understand a few things: 1. What is the overall drop in SPEC scores as a result of this patch? I understand the impact on leslie3d, but what is the overall impact? Hopefully, this is an easy question to answer: run SPEC, revert the patch, run SPEC again. I'll let others answer this (i don't have spec2006), but there have been reports filed about other spec2006 benchmarks as well on the 4.2 branch already. 2. What is the effort required to backport the necessary infrastructure from 4.3? I'm not looking for "a lot" or "is hard", but rather, "two weeks" or "six months". What needs to be backported, and what are the challenges? Including bug fixes, i'd guess 2 months to be conservative. It may be faster, of course. The main problem is that the patches are now intermingled with other changes that happened at the same time. Other than that, they should be pretty directly applicable. There are quite a few of them though (5 or 6 large patches). The other challenge is that some of the patches were written after mem-ssa merged, and that changed a lot of little infrastructure pieces. These patches will not directly apply to 4.2 anymore, and it's going to just take time to convert them. How much? A week per patch or less, i'd guess. There are no real challenges other than applying the patches and doing a lot of testing, since most of these patches were written pretty early on during the 4.3 cycle. 3. Is there any conceivable way to fix the alias analysis for 4.2 so that it is robust, but not overly conservative, even if that means a special algorithm just for 4.2? Yes, that would be a bizarre thing to do on a release branch, but humor me: is it possible, and what would it take? We had one in 4.2 prior to these fixes, but it used a huge amount of memory on large testcases. So it's possible, of course.
Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch
Daniel Berlin wrote: >> > > > It looks like your changeset listed bellow makes performance >> > > > regression ~40% on SPEC2006/leslie3d. I will try to create minimal >> > > > test for this issue this week and update you in any case. >> > The price of fixing them in 4.2 was a serious performance drop. >> >> There's the option of un-fixing them to get back to the state of 4.1 >> declaring >> them fixed in 4.3 earliest. I would like to understand a few things: 1. What is the overall drop in SPEC scores as a result of this patch? I understand the impact on leslie3d, but what is the overall impact? Hopefully, this is an easy question to answer: run SPEC, revert the patch, run SPEC again. 2. What is the effort required to backport the necessary infrastructure from 4.3? I'm not looking for "a lot" or "is hard", but rather, "two weeks" or "six months". What needs to be backported, and what are the challenges? 3. Is there any conceivable way to fix the alias analysis for 4.2 so that it is robust, but not overly conservative, even if that means a special algorithm just for 4.2? Yes, that would be a bizarre thing to do on a release branch, but humor me: is it possible, and what would it take? Please avoid answering this email with comments about the possible non-existence and/or irrelevance of 4.2. I'm about to post a separate mail about plans for 4.2.0, and such comments would be entirely germane in response to that message. But, for the purposes of this message, please assume a 4.2.0 based on the 4.2 branch in the usual way. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch
On 2/18/07, Richard Guenther <[EMAIL PROTECTED]> wrote: On 2/18/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: > On 2/17/07, H. J. Lu <[EMAIL PROTECTED]> wrote: > > On Sat, Feb 17, 2007 at 01:35:28PM +0300, Vladimir Sysoev wrote: > > > Hello, Daniel > > > > > > It looks like your changeset listed bellow makes performance > > > regression ~40% on SPEC2006/leslie3d. I will try to create minimal > > > test for this issue this week and update you in any case. > > > > > > > That is a known issue: > > > > http://gcc.gnu.org/ml/gcc/2007-01/msg00408.html > > Yes, it is something we sadly cannot do anything about without doing a > very large number of backports. > > There were some seriously broken things in 4.2's aliasing that got > fixed properly in 4.3. > The price of fixing them in 4.2 was a serious performance drop. There's the option of un-fixing them to get back to the state of 4.1 declaring them fixed in 4.3 earliest. This is fine by me, but they were rated as blockers. Richard.
Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch
On 2/18/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: On 2/17/07, H. J. Lu <[EMAIL PROTECTED]> wrote: > On Sat, Feb 17, 2007 at 01:35:28PM +0300, Vladimir Sysoev wrote: > > Hello, Daniel > > > > It looks like your changeset listed bellow makes performance > > regression ~40% on SPEC2006/leslie3d. I will try to create minimal > > test for this issue this week and update you in any case. > > > > That is a known issue: > > http://gcc.gnu.org/ml/gcc/2007-01/msg00408.html Yes, it is something we sadly cannot do anything about without doing a very large number of backports. There were some seriously broken things in 4.2's aliasing that got fixed properly in 4.3. The price of fixing them in 4.2 was a serious performance drop. There's the option of un-fixing them to get back to the state of 4.1 declaring them fixed in 4.3 earliest. Richard.
Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch
On 2/17/07, H. J. Lu <[EMAIL PROTECTED]> wrote: On Sat, Feb 17, 2007 at 01:35:28PM +0300, Vladimir Sysoev wrote: > Hello, Daniel > > It looks like your changeset listed bellow makes performance > regression ~40% on SPEC2006/leslie3d. I will try to create minimal > test for this issue this week and update you in any case. > That is a known issue: http://gcc.gnu.org/ml/gcc/2007-01/msg00408.html Yes, it is something we sadly cannot do anything about without doing a very large number of backports. There were some seriously broken things in 4.2's aliasing that got fixed properly in 4.3. The price of fixing them in 4.2 was a serious performance drop. H.J.
Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch
On Sat, Feb 17, 2007 at 01:35:28PM +0300, Vladimir Sysoev wrote: > Hello, Daniel > > It looks like your changeset listed bellow makes performance > regression ~40% on SPEC2006/leslie3d. I will try to create minimal > test for this issue this week and update you in any case. > That is a known issue: http://gcc.gnu.org/ml/gcc/2007-01/msg00408.html H.J.
Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch
> Vladimir Sysoev writes: Vladimir> It looks like your changeset listed bellow makes performance Vladimir> regression ~40% on SPEC2006/leslie3d. I will try to create minimal Vladimir> test for this issue this week and update you in any case. I believe that this is known and expected. GCC 4.2 includes some conservative alias analysis fixes for correctness that hurt performance. David
