This is the mail archive of the
mailing list for the GCC project.
[PATCH] Disable CSE skip-blocks
- From: Steven Bosscher <stevenb dot gcc at gmail dot com>
- To: gcc-patches at gcc dot gnu dot org
- Cc: Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>
- Date: Sun, 29 Oct 2006 14:35:32 +0100
- Subject: [PATCH] Disable CSE skip-blocks
In order to significantly simplify cse.c, it would be extremely helpful
if CSE's silly skip-blocks feature would go away. The attached patch
disables it. I will remove everything related to skip-blocks at a later
stage if nothing major shows up with skip-blocks disabled.
So why is skip-blocks such a headache?
- It makes CSE slower for very little benefit
- It makes it harder to have CSE work in cfglayout-mode
As most people know, cse.c does a lot more than just CSE. It "follows
paths" to have a larger scope to do CSE, addressing mode selection,
and a few other things. For path following, CSE can follow traces (i.e.
extended basic blocks) but it can also follow jumps over conditionals.
For example, given a CFG of the following form:
With this CFG and with skip-blocks, CSE works on the paths ABD and ACD.
When CSE drops from B to D, it "invalidates" everything possibly changed
in C since A, and when it drops from C to D it invalidates everything
B may have touched.
With -fno-cse-skip-blocks, CSE can follow only the extended basic block,
so it works on AB, AC, and D.
When GCC didn't have any serious global optimizer, this kind of path
following may have made sense (though I doubt it, given that it basically
is an exponential algorithm).
Nowadays the tree optimizers do most of the work and CSE path following
is just an expensive, not very effective time sink. On my collection
of preprocessed gcc files, the effect of -fno-cse-skip-blocks is a size
increase of 0.017% (235 bytes on 1370927) and a compile time decrease of
just a bit more than 1%.
The benefits would go up further if the code related to skip-blocks is
removed, because it would make it far easier to replace CSE path
following with an extended basic block CSE that stores its state tables
at the end of each basic block (as opposed to re-scanning from the start
every time, like CSE does now).
In addition, without -fcse-skip-blocks, it is going to be a *lot* easier
to make CSE work in cfglayout-mode. Right now CSE is one of only two
passes that block us from having cfglayout-mode enabled from expand all
the way down to reload. Also, because CSE doesn't work in cfglayout-mode,
GCSE also can't work in cfglayout-mode. That is really too bad because
GCSE frequently needs to do things like inserting on edges and splitting
edges, and these things are *much* easier in cfglayout-mode.
When the dataflow branch gets merged, having more passes work in
cfglayout-mode is going to be more important because cfgcleanup in
cfglayout-mode does not require iterations. This greatly simplifies the
dataflow updating code in cfgcleanup, bringing a decent speed-up there,
I believe the benefits clearly outweigh the costs of -fcse-skip-blocks,
so I'm just going to try and have it removed once again (even though
Cato is not my middle name ;-). Instead of removing all the code right
now, I'd like to propose we just disable cse skip-blocks for now, and
remove it entirely when there is sufficient proof that it is as unhelpful
for everyone else as it is for me.
This patch was bootstrapped&tested on x86_64-suse-linux-gnu.
OK for trunk?
* opts.c (decode_options): Disable CSE skip blocks.
--- opts.c (revision 118133)
+++ opts.c (working copy)
@@ -475,7 +475,6 @@ decode_options (unsigned int argc, const
flag_crossjumping = 1;
flag_optimize_sibling_calls = 1;
flag_cse_follow_jumps = 1;
- flag_cse_skip_blocks = 1;
flag_gcse = 1;
flag_expensive_optimizations = 1;
flag_ipa_type_escape = 1;