This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/29680] [4.3 Regression] Misscompilation of spec2006 gcc
- From: "dberlin at dberlin dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 9 Nov 2006 17:22:32 -0000
- Subject: [Bug tree-optimization/29680] [4.3 Regression] Misscompilation of spec2006 gcc
- References: <bug-29680-5077@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #24 from dberlin at gcc dot gnu dot org 2006-11-09 17:22 -------
Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc
On 11/9/06, Diego Novillo <dnovillo@redhat.com> wrote:
> Daniel Berlin wrote on 11/09/06 10:05:
>
> > One thing i'm going to try later is to try to partition all the
> > stores/load statements and figure out how many symbols it takes to
> > represent the results exactly (IE one symbol for each set of
> > statements that must interfere with each other, where each statement
> > can be in multiple partitions).
> >
> This is what I'm doing in memory SSA. More details later this week
> after I'm done testing and such. The difference is that partitioning is
> embedded in the actual SSA form and the partitioning heuristic can be
> changed independently of the renamer. This will let us play with a
> slider-style throttling for precision/compile-time.
>
Right, but the difference is, In the scheme i propose, you'd never
have overlapping live ranges of vuse/vdefs, and in mem-ssa, you do.
IE we wouldn't run into all the problems mem-ssa is going to bring in
this regard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680