On Mon, Aug 22, 2011 at 02:26:58PM +0300, Dimitrios Apostolou wrote: > the attached patch applies after my previous one, and actually > cancels all runtime gains from it. It doesn't make things worse than > initially, so it's not *that* bad.
You should really test it on the testcases which lead to the changes, e.g. http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01586.html You might not notice significant differences on small or common testcases, but on larger testcases it may be a question whether something can be compiled at all or not. You'll see that reverting it is actually very bad for the worst cases. > * This is the part of the compiler that makes the heaviest use of > hash tables. htab_traverse(), htab_delete(), FOR_EACH_HTAB_ELEMENT > (should that be moved in libiberty?) all iterate way too many times > over hash tables. This is all because decl/value UIDs are sparse. > * Since var-tracking is happening per-function, is there a way to > produce per-function UIDs and use those in a regular array instead > of a sparse hash table? These UIDs could be produced at tree/rtx > level, and I bet other parts in the compiler could make good use of > them. That wouldn't help you, you don't want/need to represent every DECL_UID and every VALUE seen in the whole function in every bb, only those that were actually seen there. Having (number_of_seen_decl_uids+number_of_values)*number_of_basic_blocks*sizeof(void*) memory requirements would be still bigger than the size of all the hash tables together, I think much bigger actually, and also slower when you'd need to traverse it. > * From a very wide field of view, all this DF solving reminded me a > lot of what I've seen in df-*.c. Why can't variable tracking be > integrated in the main DF pass of the compiler, the one that happens > *after* register allocation? I don't think there is any significant overlap. Yes, var-tracking is a data flow algorithm, but the code that does that is just a few lines, the big part is how the merges are done and how the tracking propagates through a basic block, and that has nothing in common with df-*.c. Jakub
