------- Comment #21 from dberlin at gcc dot gnu dot org 2006-11-09 15:06
-------
Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc
On 9 Nov 2006 11:16:12 -0000, rakdver at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> ------- Comment #20 from rakdver at gcc dot gnu dot org 2006-11-09 11:16
> -------
> > I am playing with some ideas how to fix this, unless I come up with
> something
> > soon, I will revert the patch (except for the testcase that I would like to
> > remain in the testsuite).
>
> The best I was able to do is the following patch. Virtual operand prunning
> removes all the symbols that the SMTs have in common, which causes this PR.
> The patch adds artificial "conflict" symbols to all pairs of aliasing SMTs, to
> avoid this.
This is what I was trying to do originally with multiple NONLOCAL
symbols (SMT's are going to go away) in the other testcase.
It is just too expensive generally
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).
IE if you had
load/store statements a, b, c, d
a interferes with c and d but not b
b interferes with d
You get partitions:
part1: {a, c, d}
part2: {b, d}
We then just create two symbols, and use those as the vdef/vuse syms.
This scheme is N^2 worst case, but you can choose to unify partitions
to cut down the number of symbols.
Partitions that have no shared members can also share symbols.
This would unify all of our points-to/access_can_touch_var/etc results
into one nice framework that gets very good results, and avoid the
virtual operand explosion, i think.
The real thing is that this is probably too expensive to compute 5
times per function.
We'll see.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680
