This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa] Eliminate unnecessary copies


In message <20030522153008.GA27927@atrey.karlin.mff.cuni.cz>, Jan Hubicka 
writes:
 >> It turns out a significant number of those extra insns are self copies
 >> (ie (set (reg X) (reg X)) that don't show up in the tree IL, but which
 >> are created when converting trees to RTL.   The gimplified code trips
 >> this problem more often than non-gimplified code due to our handling of
 >> NOP_EXPRs.
 >
 >Can this patch go into mainilne too?  IMO it won't hurt to kill the
 >garbage early there too.
Feel free to pull it into the mainline sources.

 >> Not bad.  Though we're still generating 25% more INSNs when using the
 >> gimplifier.  Ugh.
 >I tried to look over this problem last time I was playing around with
 >the tree-ssa code.  I didn't noticed this problem as I looked for
 >post-cse1 dumps that are still larger.  What else do you think is
 >important problem here.
It's a variety of things.  Some easy to spot, some are not.

Our handling of NOP conversions is creating quite a few unnecessary 
statements.

The way we set up loops and conditionals still sucks big time which
results in a lot of unnecessry JUMP_INSNs.

Gimplification creates a lot of unnecessary labels that hang around
until the first jump pass.

We're still getting debug line numbers for some things, even though we're
not using -g.

I'm also seeing a number of trivial redundancies we're not catching 
because of the way we handle component references.  Odds are we're going
to want to lower component references at some point to pick up all 
the silly redundancies we currently miss.

We have tons of useless variables and as a result tons of useless BIND_EXPRs.
This shows up as lots of useless lexical block scope notes in the rtl
dumps.

We have tons of useless copy statements due to "interesting" interactions
between DCE and aliasing (even though the statements in question do not
touch memory and are assigning values to variables which are never used).

Anyway, as you may be aware, we're just now starting to investigate this
stuff in detail.  I'm sure we're going to find lots of silly things.

Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]