On Tue, Aug 15, 2017 at 4:43 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > I do think you're too hung up about the placement of the phi nodes. > > It may be an issue for simple models that just walk the linearized > code directly and try to turn it into code. But the original intent of > the existing phi node code was to just be as sources of the pseudo's - > the location should be largely immaterial. > > IOW, you could think of the phi nodes as being "outside" the > instruction flow entirely, and just being the definition of the pseudo > they define. They have to be placed somewhere, but the "somewhere" is > somewhat arbitrary. I am actually with Luc on this one. The placement of the phi node is critical if you want to do the minimal phi node implementation. Even you are not doing the minimal phi node, you can't do less than the minimal phi node. Ignore the not reachable phi node for the following discussion. if we are missing one of the phi node where the minimal phi node place it (aka dominance frontier) . We are doing some thing wrong, the SSA dominance property has been violated. To reason about this, we can reference back to the SSA dominance property. When dominance of a definition ends, (in other words, dominance frontier). It need to place a phi node to join the other definition of the variable from all predecessors. Without that particular phi node, all successor of this join block will no longer able to distinguish how the multiple define merge. We can have more phi node than this, but the phi node on the dominance frontier *must not* be skipped. Skipped it cause SSA dominance property being violated. The variable is not static any more. If sparse only place the phi node on where the loads are, which a lot of case happen to be the DF (dominance frontier). In the case that DF does not have loads, that is where current sparse do wrong, sparse does not place a phi node there. Which violate the SSA property. 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
