On 08/30/2017 04:41 AM, Aldy Hernandez 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 just an oversight on my part when reviewing Sebastian's code. It's also possible refactorings have brought the scope of the vectors to a function. There shouldn't be anything overly tricky going on with that, so give it a try.
If you're looking for further cleanups, pulling the rest of the FSM bits out of tree-ssa-threadupdate.c is ripe. In particular this loop: /* Jump-thread all FSM threads before other jump-threads. */ for (i = 0; i < paths.length ();) [ ... ] If that was to get pulled out and moved into tree-ssa-threadbackwards.c, then you can probably skip the step that converts the vector of blocks into a vector of jump_thread_edge which then gets turned into an array of blocks. In theory you just turn the vector of blocks into an array of blocks to match the api for duplicate_thread_path. Jeff
