On Mon, 22 Aug 2011, Richard Guenther wrote:
On Mon, Aug 22, 2011 at 9:46 AM, Dimitrios Apostolou <ji...@gmx.net> wrote:
2011-08-22 Dimitrios Apostolou <ji...@gmx.net>
* tree-ssa-structalias.c (equiv_class_add)
(perform_var_substitution, free_var_substitution_info): Created a
new equiv_class_pool allocator pool for struct
equiv_class_label. Changed the pointer_equiv_class_table and
location_equiv_class_table hash tables to not iterate freeing all
elements in the end, but just free the pool.
Did you check if the hash functions have ever called free()? If so why
not use the pool free function so that entries can get re-used? If not,
the natural allocator would be an obstack instead.
I have not found any relevant call of htab_clear_slot(). I didn't consider
obstacks at all for all these cases, thanks for telling me, I'll see where
I can use them. As I've noted I have bootstrapped and tested all these
changes at least on x86_64 with release-checking enabled, but I plan to
test and measure all my changes together later, and hopefully on other
platforms in the future.
Thanks,
Dimitris
