This is the mail archive of the 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] Increase MAX_ALIASED_VOPS for fortran

Richard Guenther wrote on 12/14/06 10:30:
To get back pre-mem-ssa merge performance on Polyhedron.

To expand on this a bit, memory partitioning is a mechanism used to prevent the explosion of virtual operands in statements that reference memory.

If a pointer P has a set of 100 symbols in its pointed-to set, every dereference of P will require 100 virtual operands (one per symbol in the pointed-to set).

It is easy to see how this can lead to an explosion of memory consumption in big programs with big alias sets and many pointer dereferences. In its original form, Memory SSA solves this problem by dynamically creating partitions at each memory reference. Every time the renamer sees a store, it retrieves the set of symbols stored by that particular memory expression and creates a single SSA name to represent that store (known as a factored store). The next time one of those symbols in that set is loaded or stored again, the renamer links to the previous factored store.

This allows us to avoid virtual operator explosion while maintaining precision. However, it complicates the working of certain memory optimizers because it tends to create overlapping live ranges for these factored stores (i.e., the same SSA name for a factored store may be killed more than once). While I look for a way around this problem, I left out this capability from mainline.

In the meantime, instead of using this dynamic partitioning, I introduced a static partitioning scheme. The alias sets are sorted by size, an artificial tag (called memory partition tag) is created and enough members of the alias set are grouped under that tag to reduce the alias set to a manageable number.

So, an alias set may go from { a b c d e f g h i j k l } to { a b c d MPT.1 }. The tag MPT.1 will represent all the symbols { e f g h i j k l }. From then on, every memory reference using this alias set, will need 5 virtual operands instead of 14.

This does reduce alias precision, so it is important not to set it too low. The testing I did was mostly C/C++ based and since I didn't find serious runtime performance regressions I set it to 10. The Fortran regressions clearly show that 10 is too low for Fortran.

This patch is not intended as a final solution. My hope is that I can introduce the dynamic factoring without hampering the other memory optimizers, but if that is not possible, I will have to find a better static partitioning heuristic. In the meantime, Richard says that this threshold helps Polyhedron and it shouldn't affect compile times too much.

Diego, would you mind doing the testing and committing?

Will do.

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