On Wed, Aug 16, 2017 at 1:02 PM, Dibyendu Majumdar <mobile@xxxxxxxxxxxxxxx> wrote: > > I am trying to understand above - why should there be a special > treatment for gotos? A goto is simply a 'br' instruction from one BB > to another, so is there something special about it? Very good question! It's related to 'structured programming' vs. non-structured programming. If you write code which do control flow only by using if-then-else, do-while/until, while-do and C's for-loop then you know very well at each step where the code can come from, same during the linearization here in sparse, you know when your write the IR for the if-then-else or the loop what parent BB's you will have, you know that no other ones will need to be added later. Once you use gotos, it's not true anymore: if you have a label, then you will probably have some gotos going to this label, in other words, new parents for the BB. With computed gotos it's even worse: any computed-goto can possibly go to any label you have taken the address (it's GCCism, not standard C but we have to support it). This is not a problem for the method, just a little complication as we have then to delay a few things until we know all the gotos have been issued, then we know that no new parents can be added (to the BB corresponding to a label) and things can move on. It was just that the articles, for the sake of simplicity I suppose, superbly ignored the question of the gotos. So it was not as simple as taking the pseudo-code they gave and implement it, I had to find some solutions for these gotos. -- 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
