This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch Ping] [RFC] Alias export patch


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]