On Fri, Jul 07, 2017 at 10:28:03AM +0200, Luc Van Oostenryck wrote: > Another point to take in account is that the list packing was needed > because the list walking didn't like empty blocks. But months ago, > because of another bugs we made all the list walking robust against > empty blocks, so list packing shouldn't be needed anymore for > correctness. So we could in general avoid any list packing, > and only do it at some specific safe points just to save memory & > CPU time when walking lists with several blocks but few elements > (and we need to keep in mind that most lists are very very short). > > I'm more and more inclined to: > 1) in general, avoid altogether deletion from lists in favor > marking elements as being deleted, either like we do for > instructions (setting insn->bb to NULL) or storing a special > value in the ptrlist. > 2) at some specific points, as an optimization, doing a sort of > GC of the list: removing elements marked as deleted and/or > doing the list packing. > That sound to me as simple, generic and robust. Another thing that could help is that, in fact, for most lists/ list types we can't have nested list walking. In practice, BB & insn lists will be the ones really concerned and insns are immune to the problem since they are never deleted but simply marked as deleted. And this is only because the cleanup code is all done inside the ep->bbs & bb->insns loops. So at the end, I wouldn't be surprised that only the BBs are impacted, which is coherent to what the testing showed. But yes, we need to have guarantees. -- Luc -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
