This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: EON regression due to pass ordering problem (PRtree-optimize/24653)
On Sat, 2005-11-05 at 16:44 +0100, Jan Hubicka wrote:
> > On Thu, 2005-11-03 at 19:59 +0100, Jan Hubicka wrote:
> > > It was typo, the pass doing propagation is DOM.
> > > Actually there are several passes whose job description this
> > > transformation match. The addesses are constant, so CCP should do the
> > > change, VRP as well and to some extend probably FRE as well.
> > > It is simply amazing that it gets all the way to DOM :)
> > Good catch. Yes, if the address is constant, then I would expected
> > CCP and/or VRP to handle this for us. The more we can have those
> > passes deal with this stuff, the better off we're going to be.
>
> Yes. I will try to look into VRP if I can figure out why it is missing
> the transformation too. It properly computes the interval, but it won't
> do the substitution for some reason. It seems to substitute around just
> the SSA names or something similarly simple mined.
Yea, if we've computed the proper interval, then I would certainly
expect VRP to substitute the value. It may be the case that it doesn't
try to substitute symbolic values, but that's pure speculation, I
haven't looked at the code to investigate this at all.
> I would still expect ccp to be stronger than Richard's change for all
> invariant addr_exprs, but I guess I should look into tramp3d deeper if
> it does the trick on invariants or not.
Yes, CCP should be stronger for ADDR_EXPRs which are invariant.
Richard's change will handle ADDR_EXPRs which aren't invariant.
> > > 2005-11-03 Jan Hubicka <jh@suse.cz>
> > > * tree-ssa-ccp.c (ccp_fold): Strip down useless conversions.
> > Seems very reasonable to me.... And safer than doing it somewhere
> > in fold-const.
>
> Does this counts as approval for mainline? :)
Yes.
jeff