This is the mail archive of the
mailing list for the GCC project.
Re: Removing unnecessary ADDR_EXPRs
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: law at redhat dot com
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 17 May 2005 19:56:32 +0200
- Subject: Re: Removing unnecessary ADDR_EXPRs
- References: <email@example.com>
- Reply-to: Richard Guenther <richard dot guenther at gmail dot com>
On 5/17/05, Jeffrey A Law <firstname.lastname@example.org> wrote:
> This is an adaptation of some old code from Andrew Pinski to eliminate
> ADDR_EXPR expressions.
> I really want this to be done with a tree combiner, but there's some
> interesting issues we need to resolve before we can really write a tree
> 1. Need a way to tell of a particular statement is gimple or not --
> deep checking of the entire statement, not the superficial stuff
> we do right now.
> 2. A memory efficient means to change trees, and undo those changes
> if necessary.
> 3. A memory efficient means (which works in combination with #1 and
> #2) which allows us to combine multiple statements, gimplify the
> result, then compare how many statements appear in the gimplified
> result vs the number of statements we combined (ie, so that we can
> do things like 3->2 or 4->3 combinations).
> The problem with tree combination is more of memory efficiency than
> anything -- it can get ugly rather fast. I've played with a variety
> of things, but haven't come up with anything I like yet.
> In the mean time, we've got a ton of useless crud in our IL because we
> can't propagate non-constant ADDR_EXPR expressions to their use sites
> (which are usually INDIRECT_REFs or PLUS_EXPR for pointer arithmetic).
> Andrew posted some code way back in Sept which allows us to propagate
> ADDR_EXPRs. He built it as a separate pass, but it fits into our
> existing forward propagation pass reasonably well. This code handles
> the cases Andrew's code did as well as a few more. In all we see
> several thousands of ADDR_EXPRs propagated bootstrapping the compiler
> (not including the runtime system). The most common propagations
> are into INDIRECT_REF nodes (which removes the ADDR_EXPR and
> INDIRECT_REF). We also propagate into PLUS_EXPR which recovers
> array indexing from pointer arithmetic.
> One rather surprising result is the compiler is actually slightly
> faster -- I had expected it to get slightly slower as we have to
> walk over every statement in the forward propagator rather than
> just peeking at the last statement. I'm not sure if that's because
> we have fewer statements, fewer vops or some other secondary
> effect. I just know I like it :-)
> Bootstrapped and regression tested on i686-pc-linux-gnu. Fixes new
> testcases in the testsuite (of course).
We now fail building libstdc++:
In member function 'typename std::basic_filebuf<_CharT,
_Traits>::_M_seek(typename _Traits::off_type, std::_Ios_Seekdir,
typename _Traits::state_type) [with _CharT = char, _Traits =
internal compiler error: in get_indirect_ref_operands, at
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
get_indirect_ref_operands is passed (&<retval>)->_M_stateD.32454