This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Enhance reload_cse_move2add
- From: Jie Zhang <jie at codesourcery dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Fri, 02 Jul 2010 18:58:58 +0800
- Subject: Re: [PATCH] Enhance reload_cse_move2add
- References: <4C2AF62F.4030700@codesourcery.com> <4C2B753D.3050900@redhat.com> <4C2B7B54.1090803@codesourcery.com> <4C2CDA20.70803@redhat.com> <4C2CDDCE.9000807@codesourcery.com>
On 07/02/2010 02:26 AM, Jie Zhang wrote:
On 07/02/2010 02:10 AM, Jeff Law wrote:
On 06/30/10 11:13, Jie Zhang wrote:
On 07/01/2010 12:47 AM, Jeff Law wrote:
On 06/30/10 01:45, Jie Zhang wrote:
Currently reload_cse_move2add can transform
(set (REGX) (CONST_INT A))
...
(set (REGX) (CONST_INT B))
to
(set (REGX) (CONST_INT A))
...
(set (REGX) (plus (REGX) (CONST_INT B-A)))
This patch enhances it to be able to transform
(set (REGX) (CONST (PLUS (SYMBOL_REF) (CONST_INT A))))
...
(set (REGY) (CONST (PLUS (SYMBOL_REF) (CONST_INT B))))
to
(set (REGX) (CONST (PLUS (SYMBOL_REF) (CONST_INT A))))
...
(set (REGY) (CONST (PLUS (REGX) (CONST_INT B-A))))
Benchmarking using EEMBC on ARM Cortex-A8 shows performance
improvement on one test:
idctrn01: 6%
Was this a size or runtime performance improvement?
This is a runtime performance improvement.
That's quite a surprise. Just for giggles, does x86 show any change on
idctrn01? I realize it's an eembc benchmark, but if it's that sensitive
to this optimization, we ought to see some change in behaviour for x86
as well.
I have not benchmarked it on x86 using EEMBC. We use SPEC2000 for
benchmarking on x86 here. I need to ask if it's possible to setup EEMBC
for x86 in our environment.
It's not easy for me to run EEMBC on x86. We have no dedicated x86
hardware for running EEMBC.
Benchmarking using SPEC2000 on AMD Athlon64 X2 3800+ shows 0.4%
regression on CINT2000 and 0.1% improvement on CFP2000.
Bootstrapped and regression tested on x86_64.
Any thoughts on why spec2k showed a regression and was it a size or
runtime regression?
I'm not sure what caused the regressions. I'm redoing the
benchmarking. This time I do it without X and shut down running
servers as much as I can. Hope this can remove measuring error.
Strongly advised (shut down X and as many services as possible, turn off
speed scaling in the processor, etc).
Yes, I did all of these this time.
If you can get size #s, that would be interesting too -- I'd expect this
to be a small size improvement independent of the processor
architecture. Runtime performance I don't have a good feel for -- I can
easily envision cases where it's going to be better and others where
it's going to be worse.
I use 5 iterations and test -O2 and -O3 this time. It have been running
for 24 hours. It might need one or two more hours to complete. So I have
to report the results tomorrow.
Here are the new results. 'Before' is before applying my patch, 'After'
is after applying my patch.
First the results for -O3.
---------------------------------------------------
CINT2000 -O3 Before After Change
---------------------------------------------------
164.gzip 1016 1015 -0.10%
175.vpr 813 810 -0.37%
176.gcc 1048 1048 0.00%
181.mcf 625 624 -0.16%
186.crafty 1705 1706 0.06%
197.parser 769 773 0.52%
252.eon 1857 1857 0.00%
253.perlbmk 1264 1267 0.24%
254.gap 1097 1093 -0.36%
255.vortex 1513 1510 -0.20%
256.bzip2 980 980 0.00%
300.twolf 808 807 -0.12%
---------------------------------------------------
SPECint_base2000 1067 1067 0.00%
---------------------------------------------------
Notes on the above result:
* No significant changes.
---------------------------------------------------
CFP2000 -O3 Before After Change
---------------------------------------------------
168.wupwise 1187 1186 -0.08%
171.swim 1351 1364 0.96%
172.mgrid 881 882 0.11%
173.applu 1072 1069 -0.28%
177.mesa 1292 1290 -0.15%
178.galgel 1576 1583 0.44%
179.art 1013 998 -1.48%
183.equake 1442 1428 -0.97%
187.facerec 1077 1078 0.09%
188.ammp 873 876 0.34%
189.lucas 1399 1417 1.29%
191.fma3d 1078 1074 -0.37%
200.sixtrack 527 527 0.00%
301.apsi 963 970 0.73%
---------------------------------------------------
SPECfp_base2000 1088 1088 0.00%
---------------------------------------------------
Notes on the above results:
* 171: The 5 results for "Before" are 1351, 1298, 1325, 1357, 1360.
while for "After" are 1364, 1368, 1357, 1358, 1375.
Seems a real improvement.
* 179: The 5 results for "Before" are 1013, 1023, 1004, 1012, 1016.
while for "After" are 993, 998, 998, 1009, 1005.
Seems a real regression.
* 183: The 5 results for "Before" are 1442, 1442, 1442, 1443, 1441.
while for "After" are 1427, 1431, 1427, 1433, 1428.
Seems a real regression.
* 189: The 5 results for "Before" are 1396, 1399, 1401, 1394, 1399.
while for "After" are 1418, 1416, 1417, 1401, 1418.
Seems a real improvement.
Then the results for -O2:
---------------------------------------------------
CINT2000 -O2 Before After Change
---------------------------------------------------
164.gzip 1011 1012 0.10%
175.vpr 791 810 2.40%
176.gcc 1033 1031 -0.19%
181.mcf 624 624 0.00%
186.crafty 1699 1698 -0.06%
197.parser 739 736 -0.41%
252.eon 1880 1880 0.00%
253.perlbmk 1341 1342 0.07%
254.gap 1089 1094 0.46%
255.vortex 1449 1448 -0.07%
256.bzip2 970 971 0.10%
300.twolf 805 801 -0.50%
---------------------------------------------------
SPECint_base2000 1060 1062 0.19%
---------------------------------------------------
Notes on the above results:
* 175: The 5 results for "Before" are 789, 791, 789, 793, 801.
while for "After" are 810, 811, 811, 808, 808.
Seems a real improvement.
---------------------------------------------------
CFP2000 -O2 Before After Change
---------------------------------------------------
168.wupwise 1260 1232 -2.22%
171.swim 1382 1373 -0.65%
172.mgrid 905 900 -0.55%
173.applu 1049 1051 0.19%
177.mesa 1301 1300 -0.08%
178.galgel 1573 1565 -0.51%
179.art 1003 1002 -0.10%
183.equake 1352 1368 1.18%
187.facerec 1057 1062 0.47%
188.ammp 886 885 -0.11%
189.lucas 1406 1380 -1.85%
191.fma3d 1046 1048 0.19%
200.sixtrack 526 526 0.00%
301.apsi 965 955 -1.04%
---------------------------------------------------
SPECfp_base2000 1087 1083 -0.37%
---------------------------------------------------
Notes on the above results:
* 168: The 5 results for "Before" are 1261, 1231, 1261, 1253, 1260.
while for "After" are 1257, 1255, 1229, 1232, 1232.
Hard to say if it's a real regression, at least not a regression as
large as -2.22%.
* 183: The 5 results for "Before" are 1352, 1353, 1352, 1353, 1352.
while for "After" are 1368, 1368, 1368, 1367, 1367.
Seems a real improvement.
* 189: The 5 results for "Before" are 1403, 1406, 1424, 1402, 1425.
while for "After" are 1380, 1399, 1380, 1380, 1382.
Seems a real regression.
* 301: The 5 results for "Before" are 963, 967, 965, 964, 966.
while for "After" are 955, 954, 955, 954, 955.
Seems a real regression.
Summary
=======
I list all tests with ABS(change) >= 1% below:
CINT2000 Change(-O3) Change(-O2)
----------------------------------------
175.vpr -0.37% 2.40%
----------------------------------------
SPECint_base2000 0.00% 0.19%
CFP2000 Change(-O3) Change(-O2)
----------------------------------------
168.wupwise -0.08% -2.22%
171.swim 0.96% -0.65%
179.art -1.48% -0.10%
183.equake -0.97% 1.18%
189.lucas 1.29% -1.85%
301.apsi 0.73% -1.04%
----------------------------------------
SPECfp_base2000 0.00% -0.37%
Some tests have regressions while some other tests have improvements.
Some tests have regressions at one optimization level but have no minor
change or even improvements at the other optimization level.
With these test results, is it safe to commit my patch?
Regards,
--
Jie Zhang
CodeSourcery