Re: [PATCH] Fix some of the PR33870 fix fallout

["Richard Guenther" <richard dot guenther at gmail dot com>]

On 11/1/07, H.J. Lu <hjl@lucon.org> wrote:
> On Sun, Oct 28, 2007 at 09:47:08PM +0100, Richard Guenther wrote:
> > On Sun, 28 Oct 2007, H.J. Lu wrote:
> >
> > > On Sun, Oct 28, 2007 at 07:31:57PM +0100, Richard Guenther wrote:
> > > >
> > > > The PR33870 fix caused quite some compile-time regressions.  While
> > > > this unfortunately cannot be avoided completely (at least without
> > > > changing what we partition, and thus potentially causing runtime
> > > > performance regressions), the following patch makes us re-consider
> > > > a few less vars.
> > > >
> > > > It also fixes one potential problem, if we don't have flow-sensitive
> > > > alias info, we shouldn't try to prune based on the offset/size from
> > > > the referece as we really don't know what the pointer points to.
> > > >
> > > > Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.  I'll
> > > > apply this to make our internal testers pick this up tonight.
> > > >
> > >
> > > I saw 11% drop in 200.sixtrack performance on Core 2 Duo 64bit
> > > between revision 129621 and revision 129678. Is that related to
> > > the fix for PR 33870?
> >
> > This might be the case only if the VOPs were wrong before ;)  What I
> > see on some testcases is that we have before the patch
> >
> >   # VUSE <MPT.4_3>
> >   tmp_4 = (*s_4)[i_2];
> >
> > while after the patch we have
> >
> >   # VUSE <MPT.4_3, SFT.2_1, SFT.3_2>
> >   tmp_4 = (*s_4)[i_2];
> >
> > because those are not in MPT.4 but are aliased by the load.
> >
>
> This patch
>
> http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01442.html
>
> is the cause of 11% drop in 200.sixtrack performance. Has anyone
> else seen it? It is kind of odd since that patch isn't supposed
> to change code generation.

Well, the patch is supposed to make code-generation stable against
unrelated modifications.  If you look at alias dumps, there are usually
a _lot_ of vars with the same score.  The sorting change now sorts those
after UID, not random as before.

But yes, the scoring mechanism itself is not quite optimal, but I wanted
to wait for Diegos patch for PR33870 to give my (quite invasive :()
changes to the scoring mechanism a try.

Conclusion: unfortunate but not unexpected.

Richard.