This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[DF] RFC: obstacks in DF
- From: Dimitrios Apostolou <jimis at gmx dot net>
- To: gcc-patches at gcc dot gnu dot org
- Cc: Paolo Bonzini <bonzini at gnu dot org>, Andrey Belevantsev <abel at ispras dot ru>, Michael Matz <matz at suse dot de>
- Date: Mon, 20 Aug 2012 17:54:41 +0300 (EEST)
- Subject: [DF] RFC: obstacks in DF
- References: <alpine.LNX.2.02.1208181352320.20463@localhost.localdomain>
Hi,
while I was happy using obstacks in other parts of the compiler I thought
they would provide a handy solution for the XNEWVECs/XRESIZEVECs in
df-scan.c, especially df_install_refs() which is the heaviest malloc()
user after the rest of my patches.
In the process I realised that obstacks weren't exactly suitable (thanks
matz for helping on IRC), nevertheless I have a patch which is stable, a
bit faster and more memory friendly (don't know why, but RSS memory for
common non-pathological compilations, was smaller). However after trying
various incorrect changes I'm aware that there are leaks in there that
can't be closed without dirty hacks, so I gave up.
I'm posting the simplest but stable version of my changes and would really
like to hear ideas. There are "holes" in the obstack that should have been
free'd, but in the end I didn't see memory increase. I don't know what
would happen for huge functions that keep the obstack alive for long, I
didn't have such testcase. Finally, I think my next try will involve
converting the chains to pool_alloc'ed linked list, do you think that
makes sense?
Thanks,
Dimitris
Attachment:
df-obstacks.2.diff
Description: Text document