On Wed, Aug 16, 2017 at 8:00 AM, Luc Van Oostenryck <luc.vanoostenryck@xxxxxxxxx> wrote: > 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). My way to explaining myself is, the "goto" can lead to irreducible graph. It is a whole new level of complexity when irreducible graph was considering as valid input for this paper, which is *not* cover by the simple and elegant case suggested by the paper. > > 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. IMHO, not having the simple and efficient way of supporting "goto" and irreducible graph is a major shortcoming in the paper. Because those are valid input for the C source file. It make the final solution as a whole not so much simple and elegant any more. 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
