On Wed, Aug 30, 2017 at 12:41 PM, Aldy Hernandez <al...@redhat.com> wrote: > Hi! > > I'm looking at tree-ssa-threadbackward.c, where we pass around a lot > of "vec<basic_block, va_gc>" pointers representing a path through a > flow graph. > > I'm wondering why we use va_gc, when AFAICT, the paths are local to > the pass, and we can easily free them with path.release() at the end > of the pass. For that matter, it seems like we're already going > through the trouble of freeing them manually: > > vec<basic_block, va_gc> *bb_path; > vec_alloc (bb_path, 10); > ... > vec_free (bb_path); > > Am I missing something wrt vl_embed and vl_ptr magic, or would it be > acceptable to replace all these vec<basic_block, va_gc> with > vec<basic_block> and use the stack? First because the GC has > additional overhead, and second because vec<TYPE, va_gc> is fugly. > > If so, I'm assuming that similar things can be done throughout the > compiler. Why use GC, when a vector is local to a pass?
Probably history and no good reason. Feel free to make them heap vectors. Richard. > Thanks. > Aldy
