On Tue, Nov 22, 2016 at 9:27 PM, Luc Van Oostenryck <luc.vanoostenryck@xxxxxxxxx> wrote: > > Absolutely. It's what I'm doing here on my working tree. > Great. > The problem with this 'priv' is that it's, well ... private, if we > reuse it to store labels IDs it possibly can't be used anymore for > this private usage. > I would be more tempted to reuse the 'generation' field which is a long > and don't need much bits. > Of course, the real question is if that's such important to not add a new > field to struct bb. It is private to the back end. If you consider test-linearize as one of the back end, it compile the C code into readable text form. it is fine to use it. I assume the label ID is only make sense for test-linearize, not for other back end? I am also OK with just introduce one more field ID for basic blocks. There are far less basic blocks than instructions. So even size of basic block bump up by a integer is not a big deal. > Sure. > But it should be noted that this filtering stuff *could* be useful for other > things to (but I have no such uses). We can always deal with it when such usage actually come up. Chris -- 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
