This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Speed up FRE (~10% on PR34683)
On Tue, 8 Jan 2008, Daniel Berlin wrote:
> On Jan 8, 2008 4:34 AM, Richard Guenther <rguenther@suse.de> wrote:
> > On Mon, 7 Jan 2008, Daniel Berlin wrote:
> >
> > > On Jan 7, 2008 4:31 PM, Andrew MacLeod <amacleod@redhat.com> wrote:
> > > > Daniel Berlin wrote:
> > > > > On Jan 7, 2008 12:05 PM, Richard Guenther <rguenther@suse.de> wrote:
> > > > >
> >
> > and this didn't trigger during bootstrap and test either.
>
> Which is of course, no guarantee.
>
> >
> > So, how do you think we can value number a VOP to a different one?
>
> I thought i pretty well explained this above.
> See valueize_vuses/visit_reference_op_store if you don't believe we do it!
Yes, I am aware of that. But I cannot imagine a case where we can
valueize a virtual operand to a different one (apart from changing its
SSA_NAME, of course). That would mean alias information was incorrect.
Which is why I ask for an example - you can simply make one up.
> It triggered pretty often when I worked on SCCVN originally.
> If it isn't now, we are losing a lot of equivalences we could be making.
> It may be that we see more multi-use vuses than we used to (which we
> can't value number, sadly).
>
> In any case, given valuize_vuses, it's simply not safe to only sort on
> DECL_UID for the valuized vuses.
>
> I'd be happy to let you sort on DECL_UID for the others, but the
> sort_vuses call in valuize_vuses needs to sort on SSA version number
> as well.
I still don't believe that. (The operand scanner sorts after DECL_UID
because it might run into bare DECLs that have not been renamed yet)
Richard.