This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch Ping] [RFC] Alias export patch
- From: Andrey Belevantsev <abel at ispras dot ru>
- To: Richard Guenther <richard dot guenther at gmail dot com>
- Cc: Andrew MacLeod <amacleod at redhat dot com>, Diego Novillo <dnovillo at redhat dot com>, Dmitry Melnik <dm at ispras dot ru>, Daniel Berlin <dberlin at dberlin dot org>, gcc-patches at gcc dot gnu dot org
- Date: Mon, 05 Jun 2006 16:05:07 +0400
- Subject: Re: [Patch Ping] [RFC] Alias export patch
- References: <486713706.20051121174009@ispras.ru> <653679614.20051226024922@ispras.ru> <1136267119.20826.36.camel@linux.site> <1434801581.20060222170518@ispras.ru> <444E546C.5030707@redhat.com> <444E6550.5070006@redhat.com> <1146494975.3532.114.camel@pain> <4480591F.60507@ispras.ru> <84fc9c000606020902w5544fddavf0aa20e7914217f2@mail.gmail.com>
Richard Guenther wrote:
I wonder how/if you deal with the problem that the tree loop optimizers
(ivopts mostly) generate new pointers as induction variables but we don't
run may_alias after them, so possibly all interesting (performance wise)
pointers do not have updated points-to information? Do your numbers
(not performance) improve if you specify -fno-tree-loop-optimize?
Since the patch was created, we wanted to insert an additional
pass_may_alias before going out of ssa to cope with this problem.
However, as ivopts does not keep the points-to information updated, this
does not work -- gcc ICEs in verify_ssa. We've tried several times to
turn off pass_loop_optimize and insert an extra may alias pass, and that
didn't change much performance wise. Now I've tried that once again.
It gives the following (for x86):
before (with ivopts) after (no ivopts, extra alias pass)
bootstrap SPEC bootstrap SPEC
C = 433 C = 26 C = 435 C = 32
O = 523 O = 52 O = 523 O = 49
a = 10563 a = 11691 a = 10607 a = 45750
x = 1954 x = 1035 x = 2148 x = 1200
C --- add_coalesce is called for pointers with different points-to sets
O --- add_coalesce is called when one pointer has a points-to set and
the other has not
a --- new disambiguations from extended alias sets when
alias_sets_conflict_p is called
x --- new disambiguations from saved points-to sets when *_dependence
is called
All the data is with patched add_coalesce and it is almost the same with
unpatched one (as you can see from the previous mail). This data shows
~10% increase in new disambiguations from saved points-to sets, and
somehow 4x increase for SPEC using extended alias sets (probably because
of eon, but I haven't checked yet). Also, I haven't tried what that
gives us performance wise, but will do in a few days.
Andrey