public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches
@ 2005-01-31 12:33 steven at gcc dot gnu dot org
2005-01-31 12:35 ` [Bug middle-end/19721] " steven at gcc dot gnu dot org
` (41 more replies)
0 siblings, 42 replies; 45+ messages in thread
From: steven at gcc dot gnu dot org @ 2005-01-31 12:33 UTC (permalink / raw)
To: gcc-bugs
This is a meta bug for tracking what CSE still does and
other passes do not catch. After some SPEC runs with CSE
disabled completely or with at least CSE path following
disabled, it seems that we are very close to the point
where cse.c can be cleaned up significantly.
Please hang any known missed-optimization bugs involving
cse.c from this meta-bug.
--
Summary: [meta-bug] optimizations that CSE still catches
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: meta-bug
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
@ 2005-01-31 12:35 ` steven at gcc dot gnu dot org
2005-01-31 12:39 ` steven at gcc dot gnu dot org
` (40 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: steven at gcc dot gnu dot org @ 2005-01-31 12:35 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |kazu at cs dot umass dot
| |edu, pinskia at gcc dot gnu
| |dot org, dnovillo at gcc dot
| |gnu dot org, hubicka at gcc
| |dot gnu dot org
Summary|[meta-bug] optimizations |[meta-bug] optimizations
|that CSE still catches |that CSE still catches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
2005-01-31 12:35 ` [Bug middle-end/19721] " steven at gcc dot gnu dot org
@ 2005-01-31 12:39 ` steven at gcc dot gnu dot org
2005-01-31 12:40 ` kazu at cs dot umass dot edu
` (39 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: steven at gcc dot gnu dot org @ 2005-01-31 12:39 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From steven at gcc dot gnu dot org 2005-01-31 12:39 -------
To get something started, I have done SPECint and SPECfp runs on AMD64 with CVS
HEAD 20050130, unmodified vs. a cse.c with path following disabled (by setting
the max-cse-path-length to 1). The overall scores go *up* (!!!) with that
change, but some individual benchmarks regress. Still this is a lot better than
half a year ago, when terminating CSE would cause an overall regression of more
than 10%.
Diego Novillo also had his SPEC tester on i686 run, with CSE completely
disabled, and there, too, the overall performance drop was not as large as one
would maybe have expected.
Note that completely disabling is a step further than setting the
max-cse-path-length to 1. The latter effectively makes CSE a purely local pass.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
2005-01-31 12:35 ` [Bug middle-end/19721] " steven at gcc dot gnu dot org
2005-01-31 12:39 ` steven at gcc dot gnu dot org
@ 2005-01-31 12:40 ` kazu at cs dot umass dot edu
2005-01-31 12:43 ` steven at gcc dot gnu dot org
` (38 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: kazu at cs dot umass dot edu @ 2005-01-31 12:40 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
BugsThisDependsOn| |19659
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (2 preceding siblings ...)
2005-01-31 12:40 ` kazu at cs dot umass dot edu
@ 2005-01-31 12:43 ` steven at gcc dot gnu dot org
2005-01-31 12:44 ` steven at gcc dot gnu dot org
` (37 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: steven at gcc dot gnu dot org @ 2005-01-31 12:43 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From steven at gcc dot gnu dot org 2005-01-31 12:42 -------
Created an attachment (id=8112)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8112&action=view)
gcov coverage testing of CVS HEAD 20050131 on AMD64
This is the coverage data of cse.c for 517 preprocessed C files from the GCC
sources (517 files, including all components of cc1). Note especially how
ineffective fold_rtx is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (3 preceding siblings ...)
2005-01-31 12:43 ` steven at gcc dot gnu dot org
@ 2005-01-31 12:44 ` steven at gcc dot gnu dot org
2005-01-31 15:15 ` pinskia at gcc dot gnu dot org
` (36 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: steven at gcc dot gnu dot org @ 2005-01-31 12:44 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |law at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (4 preceding siblings ...)
2005-01-31 12:44 ` steven at gcc dot gnu dot org
@ 2005-01-31 15:15 ` pinskia at gcc dot gnu dot org
2005-01-31 15:24 ` dnovillo at gcc dot gnu dot org
` (35 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-01-31 15:15 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed| |1
Last reconfirmed|0000-00-00 00:00:00 |2005-01-31 15:14:49
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (5 preceding siblings ...)
2005-01-31 15:15 ` pinskia at gcc dot gnu dot org
@ 2005-01-31 15:24 ` dnovillo at gcc dot gnu dot org
2005-01-31 15:27 ` dnovillo at gcc dot gnu dot org
` (34 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: dnovillo at gcc dot gnu dot org @ 2005-01-31 15:24 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From dnovillo at gcc dot gnu dot org 2005-01-31 15:23 -------
SPEC comparisons for i686 before/after kazu's patch to completely disable CSE.
The 20050127 compiler has CSE enabled. The 20050129 compiler has CSE disabled.
Compile times for SPECint were reduced by 9%.
Compile times for SPECfp were reduced by 7.1%.
Bootstrap times were reduced by 4.5%
Comparison between 20050127/spec-20050127.stats and 20050129/spec-20050129.stats
(base)
Compiler used in 20050127/spec-20050127.stats (Before)
Compiler: gcc version 4.0.0 20050127 (experimental)
Base flags: -O2 -march=i686
Peak flags: -O3 -march=i686
Processor: Intel(R) Pentium(R) 4 CPU 2.26GHz (2259.264 Mhz)
Memory: 1034472 kB
Cache: 512 KB
Compiler used in 20050129/spec-20050129.stats (After)
Compiler: gcc version 4.0.0 20050129 (experimental)
Base flags: -O2 -march=i686
Peak flags: -O3 -march=i686
Processor: Intel(R) Pentium(R) 4 CPU 2.26GHz (2259.264 Mhz)
Memory: 1034472 kB
Cache: 512 KB
SPECint results for base
Benchmark Before After % diff
164.gzip 650.42 578.34 - 11.08%
175.vpr 421.04 418.82 - 0.53%
176.gcc 717.60 710.60 - 0.98%
181.mcf 426.30 426.49 + 0.05%
186.crafty 635.60 632.86 - 0.43%
197.parser 546.62 563.78 + 3.14%
252.eon 541.23 566.44 + 4.66%
253.perlbmk 704.34 685.23 - 2.71%
254.gap 741.52 708.46 - 4.46%
255.vortex 822.37 823.91 + 0.19%
256.bzip2 524.96 524.44 - 0.10%
300.twolf 544.79 552.95 + 1.50%
mean 594.14 588.36 - 0.97%
SPECfp result for base
Benchmark Before After % diff
168.wupwise 579.39 626.80 + 8.18%
171.swim 501.51 490.96 - 2.10%
172.mgrid 372.63 374.65 + 0.54%
173.applu 557.58 529.18 - 5.09%
177.mesa 417.03 412.20 - 1.16%
178.galgel 485.88 482.41 - 0.71%
179.art 207.13 205.69 - 0.70%
183.equake 820.26 797.45 - 2.78%
187.facerec 346.83 337.74 - 2.62%
188.ammp 343.35 333.60 - 2.84%
189.lucas 498.16 505.99 + 1.57%
191.fma3d 465.00 433.92 - 6.68%
200.sixtrack 383.56 371.22 - 3.22%
301.apsi 422.75 423.89 + 0.27%
mean 437.11 431.45 - 1.29%
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (6 preceding siblings ...)
2005-01-31 15:24 ` dnovillo at gcc dot gnu dot org
@ 2005-01-31 15:27 ` dnovillo at gcc dot gnu dot org
2005-01-31 20:14 ` stevenb at suse dot de
` (33 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: dnovillo at gcc dot gnu dot org @ 2005-01-31 15:27 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From dnovillo at gcc dot gnu dot org 2005-01-31 15:26 -------
Similarly for em64t.
Build times for SPECint were reduced by 9.2%.
Build times for SPECfp were reduced by 7.5%.
Compiler bootstrap times were reduced by 4.4%.
Comparison between 20050127/spec-20050127.stats and 20050130/spec-20050130.stats
(base)
Compiler used in 20050127/spec-20050127.stats (Before)
Compiler: gcc version 4.0.0 20050127 (experimental)
Base flags: -O2 -march=nocona
Peak flags: -O3 -march=nocona
Processor: Genuine Intel(R) CPU 2.40GHz (1866.740 Mhz)
Memory: 4064772 kB
Cache: 1024 KB
Compiler used in 20050130/spec-20050130.stats (After)
Compiler: gcc version 4.0.0 20050130 (experimental)
Base flags: -O2 -march=nocona
Peak flags: -O3 -march=nocona
Processor: Genuine Intel(R) CPU 2.40GHz (1866.740 Mhz)
Memory: 4064772 kB
Cache: 1024 KB
SPECint results for base
Benchmark Before After % diff
164.gzip 508.55 482.96 - 5.03%
175.vpr 443.91 445.11 + 0.27%
176.gcc 760.30 762.51 + 0.29%
181.mcf 397.27 397.01 - 0.07%
186.crafty 768.76 745.77 - 2.99%
197.parser 458.55 458.83 + 0.06%
252.eon 0.00 0.00 INF
253.perlbmk 758.73 767.23 + 1.12%
254.gap 836.44 834.91 - 0.18%
255.vortex 0.00 850.80 INF
256.bzip2 557.58 557.19 - 0.07%
300.twolf 576.46 557.28 - 3.33%
mean 587.55 602.07 + 2.47%
SPECfp result for base
Benchmark Before After % diff
168.wupwise 0.00 0.00 INF
171.swim 0.00 0.00 INF
172.mgrid 0.00 0.00 INF
173.applu 0.00 0.00 INF
177.mesa 767.75 765.15 - 0.34%
178.galgel 0.00 0.00 INF
179.art 735.31 741.52 + 0.84%
183.equake 1043.34 1007.83 - 3.40%
187.facerec 0.00 0.00 INF
188.ammp 558.49 536.86 - 3.87%
189.lucas 0.00 0.00 INF
191.fma3d 0.00 0.00 INF
200.sixtrack 0.00 0.00 INF
301.apsi 0.00 0.00 INF
mean 757.33 744.36 - 1.71%
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (7 preceding siblings ...)
2005-01-31 15:27 ` dnovillo at gcc dot gnu dot org
@ 2005-01-31 20:14 ` stevenb at suse dot de
2005-01-31 21:36 ` law at redhat dot com
` (32 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: stevenb at suse dot de @ 2005-01-31 20:14 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From stevenb at suse dot de 2005-01-31 20:14 -------
Subject: Re: [meta-bug] optimizations that CSE still catches
My numbers for not disabling CSE completely but disabling path following
are a lot less pessimistic. This was on an AMD Opteron at 1600MHz:
GCC was configured as: configure --enable-threads=posix --enable-languages="c,c++,f95"
GCC bootstrap times for 'make -j1 bootstrap && make install':
Bootstrap time base compiler: 2208 s
Bootstrap time peak compiler: 2150 s (-2.6%)
SPECint 64 bits
Total time for base compilation: 192 s
Total time for peak compilation: 180 s (-6.7%)
base peak peak/base
164.gzip 794 799 +0.63%
175.vpr 729 715 -1.92%
176.gcc 958 963 +0.52%
181.mcf 410 411 +0.24%
186.crafty 1362 1380 +1.32%
197.parser 558 558 =
252.eon X X
253.perlbmk 962 964 +0.21%
254.gap 774 776 +0.26%
255.vortex 1159 1162 +0.26%
256.bzip2 779 772 -0.90%
300.twolf 836 876 +4.78%
SPECfp 64 bits
Total time for base compilation: 212 s
Total time for peak compilation: 208 s (-1.9%)
base peak peak/base
168.wupwise 781 793 +1.53%
171.swim 690 687 -0.43%
172.mgrid 513 514 +0.02%
173.applu 624 624 =
177.mesa 1000 998 -0.20%
178.galgel X X
179.art 941 953 +1.28%
183.equake 817 820 +0.37%
187.facerec 674 677 +0.44%
188.ammp 859 859 =
189.lucas 858 858 =
191.fma3d 699 698 -0.14%
200.sixtrack 382 382 =
301.apsi 770 771 +0.12%
SPECint 32 bits
Total time for base compilation: 257 s
Total time for peak compilation: 246 s (-4.5%)
base peak peak/base
164.gzip 696 700 +0.57%
175.vpr 691 710 +2.74%
176.gcc 884 875 -1.02%
181.mcf 528 530 +0.38%
186.crafty 920 922 +0.22%
197.parser 629 634 +0.79%
252.eon 970 963 -0.72%
253.perlbmk 935 938 +0.32%
254.gap X X
255.vortex X X
256.bzip2 678 681 +0.04%
300.twolf 974 966 -0.82%
SPECfp 32 bits
Total time for base compilation: 210 s
Total time for peak compilation: 204 s (-2.9%)
base peak peak/base
168.wupwise 672 658 -2.08%
171.swim 692 696 +0.58%
172.mgrid 370 370 =
173.applu 580 580 =
177.mesa 678 655 -3.39%
178.galgel X X
179.art 484 483 -0.21%
183.equake 822 821 -0.12%
187.facerec 616 617 +0.16%
188.ammp 712 713 +0.14%
189.lucas 693 695 +0.20%
191.fma3d 716 716 =
200.sixtrack 422 422 =
301.apsi 685 685 =
The SPEC numbers are the mean of three runs, so that's pretty solid.
Index: params.def
===================================================================
RCS file: /cvs/gcc/gcc/gcc/params.def,v
retrieving revision 1.53
diff -u -3 -p -r1.53 params.def
--- params.def 20 Jan 2005 12:45:12 -0000 1.53
+++ params.def 31 Jan 2005 17:09:21 -0000
@@ -321,7 +321,7 @@ DEFPARAM(PARAM_MIN_CROSSJUMP_INSNS,
DEFPARAM(PARAM_MAX_CSE_PATH_LENGTH,
"max-cse-path-length",
"The maximum length of path considered in cse",
- 10, 0, 0)
+ 1, 0, 0)
/* The cost of expression in loop invariant motion that is considered
expensive. */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (8 preceding siblings ...)
2005-01-31 20:14 ` stevenb at suse dot de
@ 2005-01-31 21:36 ` law at redhat dot com
2005-02-02 9:22 ` stevenb at suse dot de
` (31 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: law at redhat dot com @ 2005-01-31 21:36 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From law at redhat dot com 2005-01-31 21:35 -------
Subject: Re: [meta-bug] optimizations that CSE still
catches
On Mon, 2005-01-31 at 20:14 +0000, stevenb at suse dot de wrote:
> ------- Additional Comments From stevenb at suse dot de 2005-01-31 20:14 -------
> Subject: Re: [meta-bug] optimizations that CSE still catches
>
> My numbers for not disabling CSE completely but disabling path following
> are a lot less pessimistic. This was on an AMD Opteron at 1600MHz:
Right. That's what I'd focus on first -- that's what I was looking
at when I realized eons ago when I realized that if we don't do a good
job at jump threading, then we have little hope of ever drastically
simplifying CSE. I've been stuck in jump threading hell ever since :-)
Note I would _STRONGLY_ recommend people look at more than just the
compiler when evaluating the old CSE code. In particular it is
important that we look at things like 64bit arithmetic on 32bit
hosts (which happens often in kernels, but not nearly as often
in user level benchmarks).
jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (9 preceding siblings ...)
2005-01-31 21:36 ` law at redhat dot com
@ 2005-02-02 9:22 ` stevenb at suse dot de
2005-02-02 11:51 ` hubicka at ucw dot cz
` (30 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: stevenb at suse dot de @ 2005-02-02 9:22 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From stevenb at suse dot de 2005-02-02 09:21 -------
Subject: Re: [meta-bug] optimizations that CSE still catches
On Monday 31 January 2005 22:35, law at redhat dot com wrote:
> Note I would _STRONGLY_ recommend people look at more than just the
> compiler when evaluating the old CSE code. In particular it is
> important that we look at things like 64bit arithmetic on 32bit
> hosts (which happens often in kernels, but not nearly as often
> in user level benchmarks).
I was told crafty has a lot of 64bits arithmetic, so the -m32
numbers for crafty should be an indication of possible regressions
in that area. And those numbers look OK to me.
If I can find some time, I'll try another benchmark suite to see
the effects of CSE path following are significant enough to still
be worth its cost.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (10 preceding siblings ...)
2005-02-02 9:22 ` stevenb at suse dot de
@ 2005-02-02 11:51 ` hubicka at ucw dot cz
2005-02-06 17:41 ` steven@gcc.gnu.org
` (29 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: hubicka at ucw dot cz @ 2005-02-02 11:51 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From hubicka at ucw dot cz 2005-02-02 11:50 -------
Subject: Re: [meta-bug] optimizations that CSE still catches
>
> ------- Additional Comments From stevenb at suse dot de 2005-02-02 09:21 -------
> Subject: Re: [meta-bug] optimizations that CSE still catches
>
> On Monday 31 January 2005 22:35, law at redhat dot com wrote:
> > Note I would _STRONGLY_ recommend people look at more than just the
> > compiler when evaluating the old CSE code. In particular it is
> > important that we look at things like 64bit arithmetic on 32bit
> > hosts (which happens often in kernels, but not nearly as often
> > in user level benchmarks).
>
> I was told crafty has a lot of 64bits arithmetic, so the -m32
> numbers for crafty should be an indication of possible regressions
> in that area. And those numbers look OK to me.
Crafty is special by using 64bit values as bitmaps rather then numbers,
so it don't do addition/multiplication and friends much that produces
most lousy artefacts.
Honza
>
> If I can find some time, I'll try another benchmark suite to see
> the effects of CSE path following are significant enough to still
> be worth its cost.
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
>
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (11 preceding siblings ...)
2005-02-02 11:51 ` hubicka at ucw dot cz
@ 2005-02-06 17:41 ` steven@gcc.gnu.org
2005-02-14 0:21 ` kazu at cs dot umass dot edu
` (28 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: steven@gcc.gnu.org @ 2005-02-06 17:41 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From steven at gcc dot gnu dot org 2005-02-06 17:41 -------
Arguably, PR16961 is not directly related. But if we fix that bug and the
similar "long long" issues on 32 bits hosts, then the "64 bits arith on 32
bits hosts" thing should be a non-issue (assuming the tree optimizers do
well).
--
What |Removed |Added
----------------------------------------------------------------------------
BugsThisDependsOn| |16961
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (12 preceding siblings ...)
2005-02-06 17:41 ` steven@gcc.gnu.org
@ 2005-02-14 0:21 ` kazu at cs dot umass dot edu
2005-02-22 6:13 ` kazu at cs dot umass dot edu
` (27 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: kazu at cs dot umass dot edu @ 2005-02-14 0:21 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
BugsThisDependsOn| |19938
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (13 preceding siblings ...)
2005-02-14 0:21 ` kazu at cs dot umass dot edu
@ 2005-02-22 6:13 ` kazu at cs dot umass dot edu
2005-02-22 7:29 ` kazu at cs dot umass dot edu
` (26 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: kazu at cs dot umass dot edu @ 2005-02-22 6:13 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
BugsThisDependsOn| |20130
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (14 preceding siblings ...)
2005-02-22 6:13 ` kazu at cs dot umass dot edu
@ 2005-02-22 7:29 ` kazu at cs dot umass dot edu
2005-02-25 22:40 ` kazu at cs dot umass dot edu
` (25 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: kazu at cs dot umass dot edu @ 2005-02-22 7:29 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
BugsThisDependsOn| |20132
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (15 preceding siblings ...)
2005-02-22 7:29 ` kazu at cs dot umass dot edu
@ 2005-02-25 22:40 ` kazu at cs dot umass dot edu
2005-03-02 11:50 ` steven at gcc dot gnu dot org
` (24 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: kazu at cs dot umass dot edu @ 2005-02-25 22:40 UTC (permalink / raw)
To: gcc-bugs
--
Bug 19721 depends on bug 19938, which changed state.
Bug 19938 Summary: Missed jump threading opportunity due to signedness difference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19938
What |Old Value |New Value
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (16 preceding siblings ...)
2005-02-25 22:40 ` kazu at cs dot umass dot edu
@ 2005-03-02 11:50 ` steven at gcc dot gnu dot org
2005-03-02 18:24 ` law at redhat dot com
` (23 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: steven at gcc dot gnu dot org @ 2005-03-02 11:50 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From steven at gcc dot gnu dot org 2005-03-02 11:50 -------
Here is a nice one:
Working on insn:
(insn 215 214 216 15 (parallel [
(set (reg:DI 176)
(ashift:DI (reg:DI 175)
(const_int 3 [0x3])))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(expr_list:REG_EQUAL (mult:DI (reg:DI 174)
(const_int 8 [0x8]))
(nil)))
Trying to fold rtx:
(mult:DI (reg:DI 174)
(const_int 8 [0x8]))
Returning new rtx:
(ashift:DI (reg:DI 174)
(const_int 3 [0x3]))
Sometimes I just hate REG_EQUAL notes...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (17 preceding siblings ...)
2005-03-02 11:50 ` steven at gcc dot gnu dot org
@ 2005-03-02 18:24 ` law at redhat dot com
2005-03-05 10:40 ` stevenb at suse dot de
` (22 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: law at redhat dot com @ 2005-03-02 18:24 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From law at redhat dot com 2005-03-02 18:23 -------
Subject: Re: [meta-bug] optimizations that CSE still
catches
On Wed, 2005-03-02 at 11:50 +0000, steven at gcc dot gnu dot org wrote:
> ------- Additional Comments From steven at gcc dot gnu dot org 2005-03-02 11:50 -------
> Here is a nice one:
>
> Working on insn:
> (insn 215 214 216 15 (parallel [
> (set (reg:DI 176)
> (ashift:DI (reg:DI 175)
> (const_int 3 [0x3])))
> (clobber (reg:CC 17 flags))
> ]) -1 (nil)
> (expr_list:REG_EQUAL (mult:DI (reg:DI 174)
> (const_int 8 [0x8]))
> (nil)))
> Trying to fold rtx:
> (mult:DI (reg:DI 174)
> (const_int 8 [0x8]))
> Returning new rtx:
> (ashift:DI (reg:DI 174)
> (const_int 3 [0x3]))
>
> Sometimes I just hate REG_EQUAL notes...
Am I missing something here? I guess I'm not sure what point you're
trying to make.
It seems to me that (reg 174) must be equal to (reg 175) for the
REG_EQUAL note to be valid. Which means they must either be set
from equivalent expressions or we must have a copy insn between
them.
In the former case (set from equivalent expressions) we should
figure out why DOM or PRE didn't catch the redundancy.
In the latter case we'd want to see why we didn't copy propagate
the copy.
[ It's possible the copy occurs due to tree->rtl expansion -- there's
still a fair number of ways to get silly copies at that phase. In
which case we need to look into ways to eliminate the silly copies.
IIRC some come from lameness in the API for some of our conversion
routines. ]
jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (18 preceding siblings ...)
2005-03-02 18:24 ` law at redhat dot com
@ 2005-03-05 10:40 ` stevenb at suse dot de
2005-03-06 0:33 ` steven at gcc dot gnu dot org
` (21 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: stevenb at suse dot de @ 2005-03-05 10:40 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From stevenb at suse dot de 2005-03-05 10:39 -------
Subject: Re: [meta-bug] optimizations that CSE still catches
> Am I missing something here? I guess I'm not sure what point you're
> trying to make.
It just seems that we could do better on initial RTL generation, e.g.
;; j = k * -1
(insn 23 21 0 (parallel [
(set (reg/v:DI 64 [ j ])
(mult:DI (reg/v:DI 67 [ k ])
(const_int -1 [0xffffffffffffffff])))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(nil))
which we later simplify in CSE:
Working on insn:
(insn 23 21 24 0 (parallel [
(set (reg/v:DI 64 [ j ])
(mult:DI (reg/v:DI 67 [ k ])
(const_int -1 [0xffffffffffffffff])))
(clobber (reg:CC 17 flags))
]) 243 {*muldi3_1_rex64} (nil)
(nil))
Trying to fold rtx:
(mult:DI (reg/v:DI 67 [ k ])
(const_int -1 [0xffffffffffffffff]))
Returning new rtx:
(neg:DI (reg/v:DI 67 [ k ]))
Similarly, on a 64-bits host:
;; j = k * 4294967295
(insn 15 13 16 (set (reg:DI 63)
(reg/v:DI 62 [ k ])) -1 (nil)
(nil))
(insn 16 15 17 (parallel [
(set (reg:DI 64)
(ashift:DI (reg:DI 63)
(const_int 32 [0x20])))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(expr_list:REG_EQUAL (mult:DI (reg/v:DI 62 [ k ])
(const_int 4294967296 [0x100000000]))
(nil)))
(insn 17 16 18 (parallel [
(set (reg:DI 65)
(minus:DI (reg:DI 64)
(reg/v:DI 62 [ k ])))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(expr_list:REG_EQUAL (mult:DI (reg/v:DI 62 [ k ])
(const_int 4294967295 [0xffffffff]))
(nil)))
(insn 18 17 0 (set (reg/v:DI 59 [ j ])
(reg:DI 65)) -1 (nil)
(nil))
which CSE turns into:
Working on insn:
(insn 15 13 16 0 (set (reg:DI 63 [ k ])
(reg/v:DI 62 [ k ])) 81 {*movdi_1_rex64} (nil)
(nil))
Trying to fold rtx:
(reg/v:DI 62 [ k ])
Returning X unchanged.
Working on insn:
(insn 16 15 17 0 (parallel [
(set (reg:DI 64)
(ashift:DI (reg:DI 63 [ k ])
(const_int 32 [0x20])))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(expr_list:REG_EQUAL (mult:DI (reg/v:DI 62 [ k ])
(const_int 4294967296 [0x100000000]))
(nil)))
Trying to fold rtx:
(mult:DI (reg/v:DI 62 [ k ])
(const_int 4294967296 [0x100000000]))
Returning new rtx:
(ashift:DI (reg/v:DI 62 [ k ])
(const_int 32 [0x20]))
Working on insn:
(insn 17 16 18 0 (parallel [
(set (reg:DI 65)
(minus:DI (reg:DI 64)
(reg/v:DI 62 [ k ])))
(clobber (reg:CC 17 flags))
]) 223 {*subdi_1_rex64} (nil)
(expr_list:REG_EQUAL (mult:DI (reg/v:DI 62 [ k ])
(const_int 4294967295 [0xffffffff]))
(nil)))
Trying to fold rtx:
(minus:DI (reg:DI 64)
(reg/v:DI 62 [ k ]))
Returning X unchanged.
Working on insn:
(insn 18 17 19 0 (set (reg/v:DI 59 [ j ])
(reg:DI 65)) 81 {*movdi_1_rex64} (nil)
(nil))
Trying to fold rtx:
(reg:DI 65)
Returning X unchanged.
These are the from the detailed .expand dump
(i.e. "cc1 t.c -O2 --fdump-rtl-expand-details -fdump-rtl-cse")
So it seems to come from the MULT_EXPR expander in this case, but
we'll have to study expand a bit closer to be sure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (19 preceding siblings ...)
2005-03-05 10:40 ` stevenb at suse dot de
@ 2005-03-06 0:33 ` steven at gcc dot gnu dot org
2005-03-06 5:59 ` law at redhat dot com
` (20 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: steven at gcc dot gnu dot org @ 2005-03-06 0:33 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From steven at gcc dot gnu dot org 2005-03-06 00:32 -------
The first case of comment #14 turns out to be PR20130.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (20 preceding siblings ...)
2005-03-06 0:33 ` steven at gcc dot gnu dot org
@ 2005-03-06 5:59 ` law at redhat dot com
2005-03-06 9:31 ` stevenb at suse dot de
` (19 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: law at redhat dot com @ 2005-03-06 5:59 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From law at redhat dot com 2005-03-06 05:59 -------
Subject: Re: [meta-bug] optimizations that CSE still
catches
On Sat, 2005-03-05 at 10:39 +0000, stevenb at suse dot de wrote:
> ------- Additional Comments From stevenb at suse dot de 2005-03-05 10:39 -------
> Subject: Re: [meta-bug] optimizations that CSE still catches
>
> > Am I missing something here? I guess I'm not sure what point you're
> > trying to make.
>
> It just seems that we could do better on initial RTL generation, e.g.
>
> ;; j = k * -1
> (insn 23 21 0 (parallel [
> (set (reg/v:DI 64 [ j ])
> (mult:DI (reg/v:DI 67 [ k ])
> (const_int -1 [0xffffffffffffffff])))
> (clobber (reg:CC 17 flags))
> ]) -1 (nil)
> (nil))
>
> which we later simplify in CSE:
>
> Working on insn:
> (insn 23 21 24 0 (parallel [
> (set (reg/v:DI 64 [ j ])
> (mult:DI (reg/v:DI 67 [ k ])
> (const_int -1 [0xffffffffffffffff])))
> (clobber (reg:CC 17 flags))
> ]) 243 {*muldi3_1_rex64} (nil)
> (nil))
> Trying to fold rtx:
> (mult:DI (reg/v:DI 67 [ k ])
> (const_int -1 [0xffffffffffffffff]))
> Returning new rtx:
> (neg:DI (reg/v:DI 67 [ k ]))
Ah. Yes. What did it look like in the tree dumps? Unless
one of the expanders is creating the negation I would think this
would be pretty easy to catch in fold-const.c
[ ... ]
>
> These are the from the detailed .expand dump
> (i.e. "cc1 t.c -O2 --fdump-rtl-expand-details -fdump-rtl-cse")
>
> So it seems to come from the MULT_EXPR expander in this case, but
> we'll have to study expand a bit closer to be sure.
expand_mult? Sigh. That's been in the back of my mind for a couple
years now -- it's probably one of the largest RTL expanders which
needs to have a lot of its functionality moved into trees.
jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (21 preceding siblings ...)
2005-03-06 5:59 ` law at redhat dot com
@ 2005-03-06 9:31 ` stevenb at suse dot de
2005-03-06 19:57 ` law at redhat dot com
` (18 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: stevenb at suse dot de @ 2005-03-06 9:31 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From stevenb at suse dot de 2005-03-06 09:30 -------
Subject: Re: [meta-bug] optimizations that CSE still catches
On Sunday 06 March 2005 06:59, law at redhat dot com wrote:
> Ah. Yes. What did it look like in the tree dumps? Unless
> one of the expanders is creating the negation I would think this
> would be pretty easy to catch in fold-const.c
This is PR20130. We don't fold -1*x to -x, ie. we never
fold the MULT_EXPR to a NEGATE_EXPR. PR20130 has a patch.
> expand_mult? Sigh. That's been in the back of my mind for a couple
> years now -- it's probably one of the largest RTL expanders which
> needs to have a lot of its functionality moved into trees.
That'd be nice.
In this case, Roger found out that for DImode negative constants
it completely bypasses expand_mult_const. Fixing that would help
for now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (22 preceding siblings ...)
2005-03-06 9:31 ` stevenb at suse dot de
@ 2005-03-06 19:57 ` law at redhat dot com
2005-03-06 22:14 ` steven at gcc dot gnu dot org
` (17 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: law at redhat dot com @ 2005-03-06 19:57 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From law at redhat dot com 2005-03-06 19:56 -------
Subject: Re: [meta-bug] optimizations that CSE still
catches
On Sun, 2005-03-06 at 09:30 +0000, stevenb at suse dot de wrote:
> ------- Additional Comments From stevenb at suse dot de 2005-03-06 09:30 -------
> Subject: Re: [meta-bug] optimizations that CSE still catches
>
> On Sunday 06 March 2005 06:59, law at redhat dot com wrote:
> > Ah. Yes. What did it look like in the tree dumps? Unless
> > one of the expanders is creating the negation I would think this
> > would be pretty easy to catch in fold-const.c
>
> This is PR20130. We don't fold -1*x to -x, ie. we never
> fold the MULT_EXPR to a NEGATE_EXPR. PR20130 has a patch.
Ok. That should be pretty easy to fix.
>
> > expand_mult? Sigh. That's been in the back of my mind for a couple
> > years now -- it's probably one of the largest RTL expanders which
> > needs to have a lot of its functionality moved into trees.
>
> That'd be nice.
>
> In this case, Roger found out that for DImode negative constants
> it completely bypasses expand_mult_const. Fixing that would help
> for now.
expand_mult, expand_divmod and the switch expanders are the biggies
IMHO. One of the tricks with the mult and divmod expanders is precisely
when should we expand them into their component operations. We clearly
don't want to do it at the very start or the very end of hte SSA path,
but somewhere in the middle.
jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (23 preceding siblings ...)
2005-03-06 19:57 ` law at redhat dot com
@ 2005-03-06 22:14 ` steven at gcc dot gnu dot org
2005-03-11 5:04 ` phython at gcc dot gnu dot org
` (16 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: steven at gcc dot gnu dot org @ 2005-03-06 22:14 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From steven at gcc dot gnu dot org 2005-03-06 22:14 -------
Just to give people an idea of how close we are to optimizing well enough that
the calls to fold_rtx in CSE are almost all no-ops, here are some numbers
taken over all cc1-i files on amd64:
Number of times fold_rtx is called: 13882333
Number of times it returns something other than the incoming rtx x: 70001
Number of times fold_rtx is called by other functions than itself: 9323647
Number of times it returns something other than x: 8526
A few rtxes that fold_rtx handles:
Loads from constant pool:
Trying to fold rtx:
(float_extend:DF (mem/u/i:SF (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [2 S4
A32]))
Trying to fold rtx:
(mem/u/i:SF (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [2 S4 A32])
Trying to fold rtx:
(symbol_ref/u:DI ("*.LC0") [flags 0x2])
Returning X unchanged.
Returning new rtx:
(const_double:SF 1.0e+0 [0x0.8p+1])
Returning new rtx:
(const_double:DF 1.0e+0 [0x0.8p+1])
Folded jumps:
Trying to fold rtx:
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0x0]))
(label_ref 73)
(pc))
Trying to fold rtx:
(pc)
Returning X unchanged.
Trying to fold rtx:
(eq (reg:CCZ 17 flags)
(const_int 0 [0x0]))
Trying to fold rtx:
(reg:SI 66 [ D.10402 ])
Returning X unchanged.
Trying to fold rtx:
(const_int 4 [0x4])
Returning X unchanged.
Returning new rtx:
(const_int 1 [0x1])
Returning new rtx:
(label_ref 73)
Apparently an equivalent expression with lower cost:
Trying to fold rtx:
(plus:QI (subreg:QI (reg:SI 251) 0)
(subreg:QI (reg:SI 251) 0))
Trying to fold rtx:
(subreg:QI (reg:SI 251) 0)
Trying to fold rtx:
(reg:SI 251)
Returning X unchanged.
Returning X unchanged.
Trying to fold rtx:
(subreg:QI (reg:SI 251) 0)
Trying to fold rtx:
(reg:SI 251)
Returning X unchanged.
Returning X unchanged.
Returning new rtx:
(ashift:QI (subreg:QI (reg:SI 251) 0)
(const_int 1 [0x1]))
Likewise:
Trying to fold rtx:
(mult:DI (reg:DI 63 [ <variable>.comb_vect.length ])
(const_int 4 [0x4]))
Returning new rtx:
(ashift:DI (reg:DI 63 [ <variable>.comb_vect.length ])
(const_int 2 [0x2]))
It'd be interesting to find out how many of these things combine and later CSE
passes would catch (or miss), and the tree-cleanup-branch compares. I will
look at the latter first.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (24 preceding siblings ...)
2005-03-06 22:14 ` steven at gcc dot gnu dot org
@ 2005-03-11 5:04 ` phython at gcc dot gnu dot org
2005-03-11 19:43 ` amylaar at gcc dot gnu dot org
` (15 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: phython at gcc dot gnu dot org @ 2005-03-11 5:04 UTC (permalink / raw)
To: gcc-bugs
--
Bug 19721 depends on bug 20130, which changed state.
Bug 20130 Summary: Fold a * -1 - 1 into ~a;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20130
What |Old Value |New Value
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (25 preceding siblings ...)
2005-03-11 5:04 ` phython at gcc dot gnu dot org
@ 2005-03-11 19:43 ` amylaar at gcc dot gnu dot org
2005-03-11 19:59 ` pinskia at gcc dot gnu dot org
` (14 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: amylaar at gcc dot gnu dot org @ 2005-03-11 19:43 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From amylaar at gcc dot gnu dot org 2005-03-11 19:43 -------
(In reply to comment #18)
> IMHO. One of the tricks with the mult and divmod expanders is precisely
> when should we expand them into their component operations. We clearly
> don't want to do it at the very start or the very end of hte SSA path,
> but somewhere in the middle.
One of the sh64 patches that I intend to merge expands signed integer
division into calculating the inverse of the divisor (at runtime) and
then multiplying the dividend with that inverse. It's broken up into
operations that assign to one pseudo register each, so this stuff gets
full exposure to cse, gcse and rtl loop optimizations. If the inverse
calculation and the mutiply with the dividend end up in the same basic
block and the inverse is only used once, some combiner patterns
combine & split this stuff again to get a more scheduler-friendly data
flow.
Do you think we should have machine-dependent tree expanders so that
such details can already be exposed to (g)cse and loop optimizations at
the tree level?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (26 preceding siblings ...)
2005-03-11 19:43 ` amylaar at gcc dot gnu dot org
@ 2005-03-11 19:59 ` pinskia at gcc dot gnu dot org
2005-03-16 14:53 ` kazu at cs dot umass dot edu
` (13 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-03-11 19:59 UTC (permalink / raw)
To: gcc-bugs
--
Bug 19721 depends on bug 20132, which changed state.
Bug 20132 Summary: Pessimization of induction variable and missed hoisting opportunity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20132
What |Old Value |New Value
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (27 preceding siblings ...)
2005-03-11 19:59 ` pinskia at gcc dot gnu dot org
@ 2005-03-16 14:53 ` kazu at cs dot umass dot edu
2005-03-17 8:22 ` aoliva at gcc dot gnu dot org
` (12 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: kazu at cs dot umass dot edu @ 2005-03-16 14:53 UTC (permalink / raw)
To: gcc-bugs
--
Bug 19721 depends on bug 19788, which changed state.
Bug 19788 Summary: Inconsistent handling of -1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19788
What |Old Value |New Value
----------------------------------------------------------------------------
Status|WAITING |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (28 preceding siblings ...)
2005-03-16 14:53 ` kazu at cs dot umass dot edu
@ 2005-03-17 8:22 ` aoliva at gcc dot gnu dot org
2005-04-13 18:11 ` pinskia at gcc dot gnu dot org
` (11 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: aoliva at gcc dot gnu dot org @ 2005-03-17 8:22 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
BugsThisDependsOn| |20514
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (29 preceding siblings ...)
2005-03-17 8:22 ` aoliva at gcc dot gnu dot org
@ 2005-04-13 18:11 ` pinskia at gcc dot gnu dot org
2005-04-13 18:15 ` pinskia at gcc dot gnu dot org
` (10 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-04-13 18:11 UTC (permalink / raw)
To: gcc-bugs
--
Bug 19721 depends on bug 19659, which changed state.
Bug 19659 Summary: GCC does not remove an "if" statement that never triggers.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19659
What |Old Value |New Value
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (30 preceding siblings ...)
2005-04-13 18:11 ` pinskia at gcc dot gnu dot org
@ 2005-04-13 18:15 ` pinskia at gcc dot gnu dot org
2005-04-16 15:15 ` steven at gcc dot gnu dot org
` (9 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-04-13 18:15 UTC (permalink / raw)
To: gcc-bugs
--
Bug 19721 depends on bug 19789, which changed state.
Bug 19789 Summary: tree optimizers do not know that constant global variables do not change
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19789
What |Old Value |New Value
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (31 preceding siblings ...)
2005-04-13 18:15 ` pinskia at gcc dot gnu dot org
@ 2005-04-16 15:15 ` steven at gcc dot gnu dot org
2005-04-26 17:35 ` bonzini at gcc dot gnu dot org
` (8 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: steven at gcc dot gnu dot org @ 2005-04-16 15:15 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From steven at gcc dot gnu dot org 2005-04-16 15:15 -------
It is apparently not possible to convince people that any optimizations
in CSE can be removed, so working on this is pointless for me. See
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01498.html.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (32 preceding siblings ...)
2005-04-16 15:15 ` steven at gcc dot gnu dot org
@ 2005-04-26 17:35 ` bonzini at gcc dot gnu dot org
2005-05-06 14:02 ` pinskia at gcc dot gnu dot org
` (7 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: bonzini at gcc dot gnu dot org @ 2005-04-26 17:35 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From bonzini at gcc dot gnu dot org 2005-04-26 17:35 -------
Another thing that CSE does is promoting paradoxical subregs to regs. On
PowerPC at least, recursive calls of fold_rtx are almost ineffective except for
this. Such promotion helps because equiv_constant does not look into subregs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (33 preceding siblings ...)
2005-04-26 17:35 ` bonzini at gcc dot gnu dot org
@ 2005-05-06 14:02 ` pinskia at gcc dot gnu dot org
2005-07-19 14:13 ` falk at debian dot org
` (6 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-05-06 14:02 UTC (permalink / raw)
To: gcc-bugs
--
Bug 19721 depends on bug 19791, which changed state.
Bug 19791 Summary: [tcb] A constant not fully propagated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19791
What |Old Value |New Value
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (34 preceding siblings ...)
2005-05-06 14:02 ` pinskia at gcc dot gnu dot org
@ 2005-07-19 14:13 ` falk at debian dot org
2005-08-17 8:04 ` bonzini at gcc dot gnu dot org
` (5 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: falk at debian dot org @ 2005-07-19 14:13 UTC (permalink / raw)
To: gcc-bugs
--
Bug 19721 depends on bug 16961, which changed state.
Bug 16961 Summary: Poor x86-64 performance with 128bit ints
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16961
What |Old Value |New Value
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (35 preceding siblings ...)
2005-07-19 14:13 ` falk at debian dot org
@ 2005-08-17 8:04 ` bonzini at gcc dot gnu dot org
2005-08-17 19:42 ` law at redhat dot com
` (4 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: bonzini at gcc dot gnu dot org @ 2005-08-17 8:04 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-17 08:03 -------
This small testcase is a typical case of the optimizations that CSE path
following catches on PowerPC:
unsigned outcnt;
extern void flush_outbuf(void);
void
bi_windup(unsigned char *outbuf, unsigned char bi_buf)
{
outbuf[outcnt] = bi_buf;
if (outcnt == 16384)
flush_outbuf();
outbuf[outcnt] = bi_buf;
}
Loading outcnt takes *three* insns: one to load the high part of the address,
one to load the low part, one to load from memory. CSE reduces them to two by
combining the loading of the low part with the load from memory. With CSE path
following, in addition, CSE is able to factor the loads of the high part of the
address, and do just one of them.
Now here comes GCSE. If CSE path following is on, GCSE sees that the third
occurrence of outcnt is the same as the second, and eliminates it. If it is
off, GCSE is wasted to factor the loading of the address high parts.
So, if we remove a pseudo-global cse pass by disabling path following, it would
make sense to bump the default max-gcse-passes to 2.
Paolo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (36 preceding siblings ...)
2005-08-17 8:04 ` bonzini at gcc dot gnu dot org
@ 2005-08-17 19:42 ` law at redhat dot com
2005-08-17 20:18 ` paolo dot bonzini at lu dot unisi dot ch
` (3 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: law at redhat dot com @ 2005-08-17 19:42 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From law at redhat dot com 2005-08-17 19:31 -------
Subject: Re: [meta-bug] optimizations that CSE still
catches
On Wed, 2005-08-17 at 08:03 +0000, bonzini at gcc dot gnu dot org wrote:
> ------- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-17 08:03 -------
> This small testcase is a typical case of the optimizations that CSE path
> following catches on PowerPC:
>
> unsigned outcnt;
> extern void flush_outbuf(void);
>
> void
> bi_windup(unsigned char *outbuf, unsigned char bi_buf)
> {
> outbuf[outcnt] = bi_buf;
> if (outcnt == 16384)
> flush_outbuf();
> outbuf[outcnt] = bi_buf;
> }
>
> Loading outcnt takes *three* insns: one to load the high part of the address,
> one to load the low part, one to load from memory. CSE reduces them to two by
> combining the loading of the low part with the load from memory. With CSE path
> following, in addition, CSE is able to factor the loads of the high part of the
> address, and do just one of them.
>
> Now here comes GCSE. If CSE path following is on, GCSE sees that the third
> occurrence of outcnt is the same as the second, and eliminates it. If it is
> off, GCSE is wasted to factor the loading of the address high parts.
>
> So, if we remove a pseudo-global cse pass by disabling path following, it would
> make sense to bump the default max-gcse-passes to 2.
Presumably the store into outbuf prevents the SSA optimizers from
commonizing the first two loads of outcnt and the call to flush_outbuf
prevents the SSA optimizers from commonizing the last load of outcnt on
the path which bypasses the call to flush_outbuf. Right?
Jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (37 preceding siblings ...)
2005-08-17 19:42 ` law at redhat dot com
@ 2005-08-17 20:18 ` paolo dot bonzini at lu dot unisi dot ch
2005-08-18 7:56 ` bonzini at gcc dot gnu dot org
` (2 subsequent siblings)
41 siblings, 0 replies; 45+ messages in thread
From: paolo dot bonzini at lu dot unisi dot ch @ 2005-08-17 20:18 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From paolo dot bonzini at lu dot unisi dot ch 2005-08-17 20:07 -------
Subject: Re: [meta-bug] optimizations that CSE still
catches
>> unsigned outcnt;
>> extern void flush_outbuf(void);
>>
>> void
>> bi_windup(unsigned char *outbuf, unsigned char bi_buf)
>> {
>> outbuf[outcnt] = bi_buf;
>> if (outcnt == 16384)
>> flush_outbuf();
>> outbuf[outcnt] = bi_buf;
>> }
>>
>>
>Presumably the store into outbuf prevents the SSA optimizers from
>commonizing the first two loads of outcnt and the call to flush_outbuf
>prevents the SSA optimizers from commonizing the last load of outcnt on
>the path which bypasses the call to flush_outbuf. Right?
>
>
Not really. First of all, as stevenb pointed out on IRC, this is quite
specific to powerpc-apple-darwin and other targets where programs are
compiled as PIC by default. Steven's SPEC testing under Linux has not
shown this behavior, but shared libraries there *will* suffer from the
same problem!
We'd want the code to become
void
bi_windup(unsigned char *outbuf, unsigned char bi_buf)
{
int t1 = outcnt;
outbuf[t1] = bi_buf;
int t2 = outcnt, t3;
if (t2 == 16384) {
flush_outbuf();
t3 = outcnt;
} else
t3 = t2;
outbuf[t3] = bi_buf;
}
If we disable CSE path following, and keep only one GCSE pass, we
"waste" the opportunity to do this optimization, because we generate
temporaries for the partially redundant address of outcnt. With two
GCSE passes, the second is able to eliminate the partially redundant load.
Of course what we really miss is load PRE on the tree level, but it is
good that --param max-gcse-passes=2 can be a replacement of
-fcse-skip-blocks -fcse-follow-jumps. Testing mainline GCC against a
patch including no path following + 2 GCSE passes + my forward
propagation pass, I'm seeing SPEC improvements of +2 to +8% on
powerpc-apple-darwin.
Paolo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (38 preceding siblings ...)
2005-08-17 20:18 ` paolo dot bonzini at lu dot unisi dot ch
@ 2005-08-18 7:56 ` bonzini at gcc dot gnu dot org
2005-09-16 8:10 ` steven at gcc dot gnu dot org
2005-09-29 12:40 ` steven at gcc dot gnu dot org
41 siblings, 0 replies; 45+ messages in thread
From: bonzini at gcc dot gnu dot org @ 2005-08-18 7:56 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
BugsThisDependsOn| |23455
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (39 preceding siblings ...)
2005-08-18 7:56 ` bonzini at gcc dot gnu dot org
@ 2005-09-16 8:10 ` steven at gcc dot gnu dot org
2005-09-29 12:40 ` steven at gcc dot gnu dot org
41 siblings, 0 replies; 45+ messages in thread
From: steven at gcc dot gnu dot org @ 2005-09-16 8:10 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
BugsThisDependsOn| |23911
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
` (40 preceding siblings ...)
2005-09-16 8:10 ` steven at gcc dot gnu dot org
@ 2005-09-29 12:40 ` steven at gcc dot gnu dot org
41 siblings, 0 replies; 45+ messages in thread
From: steven at gcc dot gnu dot org @ 2005-09-29 12:40 UTC (permalink / raw)
To: gcc-bugs
--
Bug 19721 depends on bug 23911, which changed state.
Bug 23911 Summary: Failure to propagate constants from a const initializer for _Complex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23911
What |Old Value |New Value
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Status|NEW |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
[not found] <bug-19721-4@http.gcc.gnu.org/bugzilla/>
2013-05-09 0:32 ` amylaar at gcc dot gnu.org
@ 2013-05-09 10:40 ` steven at gcc dot gnu.org
1 sibling, 0 replies; 45+ messages in thread
From: steven at gcc dot gnu.org @ 2013-05-09 10:40 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
--- Comment #27 from Steven Bosscher <steven at gcc dot gnu.org> 2013-05-09 10:39:57 UTC ---
(In reply to comment #26)
> With TARGET_LEGITIMATE_ADDRESS_P rejecting (costly) symbols_refs inside
> memory references, cse_local brings the number of __malloc_av references down
> when compiling newlib's malloc-r.c:
Can you please open a fresh PR for this, with the information necessary
to reproduce this problem, and make the new PR block this one? This PR
is a meta-bug, reporting specific problems is best done in new PRs.
^ permalink raw reply [flat|nested] 45+ messages in thread
* [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
[not found] <bug-19721-4@http.gcc.gnu.org/bugzilla/>
@ 2013-05-09 0:32 ` amylaar at gcc dot gnu.org
2013-05-09 10:40 ` steven at gcc dot gnu.org
1 sibling, 0 replies; 45+ messages in thread
From: amylaar at gcc dot gnu.org @ 2013-05-09 0:32 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
--- Comment #26 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2013-05-09 00:32:28 UTC ---
The tree optimizers have become extremely aggressive on constant propagation,
so cse is needed more than ever to undo the damage.
With TARGET_LEGITIMATE_ADDRESS_P rejecting (costly) symbols_refs inside
memory references, cse_local brings the number of __malloc_av references down
when compiling newlib's malloc-r.c:
$ grep -c 'symbol_ref.*__malloc_av_' mallocr-4.4.i.*
mallocr-4.4.i.165r.expand:70
mallocr-4.4.i.166r.vregs:35
mallocr-4.4.i.167r.into_cfglayout:35
mallocr-4.4.i.168r.jump:70
mallocr-4.4.i.169r.subreg1:35
mallocr-4.4.i.170r.dfinit:35
mallocr-4.4.i.171r.cse1:70
mallocr-4.4.i.172r.fwprop1:41
mallocr-4.4.i.173r.cprop1:54
mallocr-4.4.i.175r.hoist:42
mallocr-4.4.i.176r.cprop2:30
mallocr-4.4.i.178r.cse_local:26
^ permalink raw reply [flat|nested] 45+ messages in thread
end of thread, other threads:[~2013-05-09 10:40 UTC | newest]
Thread overview: 45+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-01-31 12:33 [Bug middle-end/19721] New: [meta-bug] optimizations that CSE still catches steven at gcc dot gnu dot org
2005-01-31 12:35 ` [Bug middle-end/19721] " steven at gcc dot gnu dot org
2005-01-31 12:39 ` steven at gcc dot gnu dot org
2005-01-31 12:40 ` kazu at cs dot umass dot edu
2005-01-31 12:43 ` steven at gcc dot gnu dot org
2005-01-31 12:44 ` steven at gcc dot gnu dot org
2005-01-31 15:15 ` pinskia at gcc dot gnu dot org
2005-01-31 15:24 ` dnovillo at gcc dot gnu dot org
2005-01-31 15:27 ` dnovillo at gcc dot gnu dot org
2005-01-31 20:14 ` stevenb at suse dot de
2005-01-31 21:36 ` law at redhat dot com
2005-02-02 9:22 ` stevenb at suse dot de
2005-02-02 11:51 ` hubicka at ucw dot cz
2005-02-06 17:41 ` steven@gcc.gnu.org
2005-02-14 0:21 ` kazu at cs dot umass dot edu
2005-02-22 6:13 ` kazu at cs dot umass dot edu
2005-02-22 7:29 ` kazu at cs dot umass dot edu
2005-02-25 22:40 ` kazu at cs dot umass dot edu
2005-03-02 11:50 ` steven at gcc dot gnu dot org
2005-03-02 18:24 ` law at redhat dot com
2005-03-05 10:40 ` stevenb at suse dot de
2005-03-06 0:33 ` steven at gcc dot gnu dot org
2005-03-06 5:59 ` law at redhat dot com
2005-03-06 9:31 ` stevenb at suse dot de
2005-03-06 19:57 ` law at redhat dot com
2005-03-06 22:14 ` steven at gcc dot gnu dot org
2005-03-11 5:04 ` phython at gcc dot gnu dot org
2005-03-11 19:43 ` amylaar at gcc dot gnu dot org
2005-03-11 19:59 ` pinskia at gcc dot gnu dot org
2005-03-16 14:53 ` kazu at cs dot umass dot edu
2005-03-17 8:22 ` aoliva at gcc dot gnu dot org
2005-04-13 18:11 ` pinskia at gcc dot gnu dot org
2005-04-13 18:15 ` pinskia at gcc dot gnu dot org
2005-04-16 15:15 ` steven at gcc dot gnu dot org
2005-04-26 17:35 ` bonzini at gcc dot gnu dot org
2005-05-06 14:02 ` pinskia at gcc dot gnu dot org
2005-07-19 14:13 ` falk at debian dot org
2005-08-17 8:04 ` bonzini at gcc dot gnu dot org
2005-08-17 19:42 ` law at redhat dot com
2005-08-17 20:18 ` paolo dot bonzini at lu dot unisi dot ch
2005-08-18 7:56 ` bonzini at gcc dot gnu dot org
2005-09-16 8:10 ` steven at gcc dot gnu dot org
2005-09-29 12:40 ` steven at gcc dot gnu dot org
[not found] <bug-19721-4@http.gcc.gnu.org/bugzilla/>
2013-05-09 0:32 ` amylaar at gcc dot gnu.org
2013-05-09 10:40 ` steven at gcc dot gnu.org
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).