On 10/26/14 15:34, Sebastian Pop wrote:

I have tried to understand why the code generation part ICEs on coremark: the
first problem that I have seen is that tree-ssa-threadupdate.c does not handle
more than a joiner block per path to be threaded, so we would not be able to
jump thread accross the joiners of the if condition and the joiner of the switch
condition: i.e., these paths
Right. There's nothing I can think of inherently that makes that impossible, it's just not something the code currently tries to support. I suspect there's a few places that need light generalization. I can offhand think of one or two.

It's not lost on me that what we're building is a specialized region cloner. I keep wanting to go back and see if there's a representation where we have an incoming edge, series of blocks and an outgoing edge. The concept of a "join" block really isn't important. It's just a block that we want to copy for which we don't know its destination.

Anyway, within that representation, I think the way to wire up the edges is simple if we build a map at the beginning of the process. The set of blocks in the path all get clones. There's a single edge into the cloned path (the incoming edge) and a single edge out (the edge corresponding to the statically computed destination of the path). Edges that were interior in the original path are kept interior in the clone. Edges that reached outside the original path go from the clone to the original destinations outside the path. It's a SEME region.



Another problem is that we attach the path to be threaded to the ->aux field of
the first edge in the path, such that we would have to cancel some of the paths
because we cannot keep track of all the paths to be threaded.
What I can easily see is cases where you have two paths starting at a particular node where one path is a strict subset of another path. Assuming the amount of copying we're doing is reasonable, then you'd want to keep just the longer path

But I don't think that's the case you're struggling with. We could (for example) have a case where all the successors of a join block become threadable, possibly to different destinations.

That would argue that we really want to handle the threads off a different data structure than e->aux.


jeff

Reply via email to