This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] Eliminate unnecessary copies
- From: law at redhat dot com
- To: Jan Hubicka <jh at suse dot cz>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 22 May 2003 11:34:01 -0600
- Subject: Re: [tree-ssa] Eliminate unnecessary copies
- Reply-to: law at redhat dot com
In message <20030522153008.GA27927@atrey.karlin.mff.cuni.cz>, Jan Hubicka
>> 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
>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
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
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.