------- Comment #2 from jakub at gcc dot gnu dot org 2010-02-12 16:44 -------
So, when vt_find_locations visits the second time bb 4 in bar, it copies bb 4's
out set (just mentioning the important items):
name: c D.1235
offset 0
(value/s/u:SI 30:3972 @0x211f100/0x214cfa0)
(value/s/u:SI 30:3972 @0x211f100/0x214cfa0)
offset 0
(reg:SI 0 ax)
(mem/f/c/i:SI (value/s/u:SI 20:3962 @0x211f010/0x214cd50) [2 cD.1235+0 S4
A32])
(value/s/u:SI 20:3962 @0x211f010/0x214cd50)
offset 0
(plus:SI (value/s/u:SI 19:19 @0x211eff8/0x214cdb0)
(const_int 8 [0x8]))
(value/s/u:SI 19:19 @0x211eff8/0x214cdb0)
offset 0
(value/s/u:SI 2:2 @0x211ec68/0x21338b0)
(value/s/u:SI 2:2 @0x211ec68/0x21338b0)
offset 0
(reg/f:SI 6 bp)
(value/s/u:SI 6:6 @0x211ecc8/0x21337e0)
(value/s/u:SI 13:13 @0x211ee00/0x2133910)
(value/s/u:SI 19:19 @0x211eff8/0x214cdb0)
and bb 3's out set:
name: c D.1235
offset 0
(value/s/u:SI 9:9 @0x211ed10/0x2133720)
(value/s/u:SI 9:9 @0x211ed10/0x2133720)
offset 0
(mem/f/c/i:SI (value/s/u:SI 8:3945 @0x211ecf8/0x2133750) [2 cD.1235+0 S4
A32])
(value/s/u:SI 8:3945 @0x211ecf8/0x2133750)
offset 0
(plus:SI (value/s/u:SI 2:2 @0x211ec68/0x21338b0)
(const_int 8 [0x8]))
(value/s/u:SI 2:2 @0x211ec68/0x21338b0)
offset 0
(reg/f:SI 6 bp)
(value/s/u:SI 6:6 @0x211ecc8/0x21337e0)
(value/s/u:SI 13:13 @0x211ee00/0x2133910)
But as the VALUEs are different and some values are embedded inside of the
MEMs/PLUSs, intersect_loc_chains doesn't figure out that value 9:9 is actually
equivalent to value 30:3972. Wonder whether intersect_loc_chains needs to do a
for_each_rtx search, comparing stuff other than values right away and comparing
values using recursive intersect_loc_chains. And whether this wouldn't be too
expensive.
Wonder if http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01016.html could make a
difference here (i.e. if the star canonicalization would help), but then
I haven't heard a response to my query in
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01490.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43051
