On Tue, Aug 15, 2017 at 1:14 PM, Luc Van Oostenryck
<luc.vanoostenryck@xxxxxxxxx> wrote:
>
> For information, the current SSA construction is very broken,
> both in simplify_one_symbol() (the main SSA construction)
> and simplify_loads() (which also creates phi-nodes). They both
> are 'load-driven' which is OK but they both put the phi-nodes
> where the load is while phi-nodes need to placed where branches
> meet. The loads are often placed in a BB following where the
> join-point. Often this *seems* to be OK but in fact is very wrong
> and create all sort of problems a bit everywhere
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.
That said, I like your new ssa construction -independently- of that
issue - the old SSA constructor really was very ad-hoc. Look through
the git history if you don't believe me ;)
Linus
--
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
