Hi Chris, On 16 August 2017 at 13:50, Christopher Li <sparse@xxxxxxxxxxx> wrote: > On Wed, Aug 16, 2017 at 8:39 AM, Dibyendu Majumdar > <mobile@xxxxxxxxxxxxxxx> wrote: >> It is an advantage and a disadvantage in the sense that it makes SSA >> construction not reusable - or have I misunderstood? Looking at the > > Not sure I understand the question. I meant that it would nice to save a function like SSA(linear input) -> SSA output - because then you can rerun the SSA conversion several times during optimization. > >> implementation I felt that it could be run as a second phase - is that >> assumption wrong? > > That assumption is correct. But not having the advantage the paper > claim any more. > I think there is still an advantage as the implementation is bottom up, uses memoization / dynamic programming techniques, and hence might actually be quite efficient. I think Luc is better placed to comment on this. >> >> I am just trying to understand the issue as it seems the paper claims >> it creates pruned SSA for all programs - not just reducible control >> flow. Have you contacted the authors regarding the issues you are > > Sorry I might mislead you. I said the paper solution for irreducable > graph is *not* simple *nor* efficient any more. The paper do suggest > a way to do it. But I consider that way complex (in execution time sense). > I haven't take a closer look at the code yet. > >> having with gotos? Might be worth doing so. > > My reading of the paper is yes. Having "goto" will interrupt that > CFG less method. It can also lead to irreducible graph. Which means > extra step to clean it up. That extra step is expensive in the O() terms. > But Luc's implementation handles gotos fine without the extra phase - hence please please try out the implementation before arriving at conclusions. Regards Dibyendu -- 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
