This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] where to fix this?
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: law at redhat dot com
- Cc: Roger Sayle <roger at eyesopen dot com>,gcc at gcc dot gnu dot org,Dale Johannesen <dalej at apple dot com>,Jan Hubicka <hubicka at ucw dot cz>,Jan Hubicka <jh at suse dot cz>
- Date: Tue, 6 Jan 2004 19:40:11 -0500
- Subject: Re: [tree-ssa] where to fix this?
- References: <200401070029.i070T9OL019897@speedy.slc.redhat.com>
On Jan 6, 2004, at 7:29 PM, firstname.lastname@example.org wrote:
In message <FFCAFC47-40A3-11D8-8CD1-000A95DA505C@dberlin.org>, Daniel
Berlin wrThat's a bit harsh of a statement (not that i'm surprised, however).
Apparently your code was buggy or you weren't looking at the right
When we follow def-use chains in the dominator optimizer to
and simplify operands. The stuff we do right now is pretty simple,
it's one of the two areas of the dominator optimizer that I do expect
will need to be extended.
I tried a variant on this back right before we had renaming SSA.
It was a forward and backward substitution pass, which tried to see if
any of the resulting expressions were GIMPLE (after trying folding, of
They never were.
However, I was mainly interested in substitution of array indexing
expressions, for the purposes of simplifying array access expressions.
I've definitely got cases where were substitution & folding results in
a gimple expression.
Wake me when you've got percentage speed increase or decreased memory
usage (due to less expressions) numbers.
Simply the number of expressions eliminated means nothing really by