On Mon, Aug 20, 2012 at 2:03 PM, Paolo Bonzini <bonz...@gnu.org> wrote: > Il 19/08/2012 18:55, Richard Guenther ha scritto: >>> > Initially I had one obstack per struct graph, which was better than using >>> > XNEW for every edge, but still obstack_init() called from new_graph() was >>> > too frequent. >>> > >>> > So in this iteration of the patch the obstack is static global, >>> > initialised >>> > once and never freed. Please advise on whether this is acceptable, and >>> > also >>> > where I should initialise the obstack once, and avoid checking if it's >>> > NULL >>> > in every use. >>> > >>> > Minor speed gains (couple of ms), tested with pre-C++ conversion snapshot, >>> > I'll retest soon and post update. >> Either an obstack per graph or the ability to specify an obstack for >> allocation. >> A global obstack with global lifetime is bad IMHO. > > Dimitrios's patch has a per-file obstack with per-pass lifetime, which I > think is the right solution---but putting graph_obstack as a static > variable in graphds.h is uuuugly. You can just move the declaration to > each file separately, and give it a better name perhaps (e.g. > loop_graph_obstack).
Well, I see that the way it is constructed is that you can at most have a single live graph at the same time (using the same obstack). That's a big limitation IMHO. Now, if the users would manage the obstack completely and instead would obstack_init()/free() them that would be different. Of course the outcome is exactly as with the initial patch having the obstack per struct graph. The present patch has too much low-level stuff exposed and does not easily allow putting other data on the same obstack. So I'd vote for managing the obstack completely in the caller for flexibility. Some may want to allocate auxiliar data on the same obstack for example. Richard. > Paolo
