<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Feb 12, 2015 at 12:56 PM, Shankar Easwaran <span dir="ltr"><<a href="mailto:shankare@codeaurora.org" target="_blank">shankare@codeaurora.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On 2/12/2015 2:26 PM, Rui Ueyama wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Looks like there's a bug. It's weird that the existing test didn't catch<br>
that. I'll probably need to fix the ordinal of alias atoms.<br>
<br>
LayoutPass is retired peacefully. I know that code very well, because after<br>
you added code to that file for follow-on/followed-by relations, I spend so<br>
much effort improving that functionality while keeping the original<br>
intention. I refactored it for readability, fixed various bugs, improved<br>
performance (originally it was even quadratic), and added bunch of<br>
(overly-designed in hindsight) assertions to verify that too-flexible<br>
complex data structure is in a well-formed shape. Eventually I had to<br>
conclude that this was not a good design after all -- it was too<br>
complicated compared to what it would do. So I cannot agree.<br>
</blockquote></span>
The whole point of LayoutPass was it was reference based previously and now its ordinal based. It was more generic previously(though we didnt need that complexity).</blockquote><div><br></div><div>Shankar,</div><div><br></div><div>You made a good point that the previous design was more generic. The point is that being more generic is not always a good thing. It comes with cost, and the cost could be very high. For example, I've seen many systems whose configuration file is actually Turing complete like a scripting language. It was sometimes extremely hard to understand a config file and no one even tried to touch it. Generic systems are tend to be hard to understand. Choosing the right balance is important.</div><div><br></div><div>As to LayoutPass, we basically wanted to do some sort of topological sorting on the graph of atoms. Conceptually it sounds easy but in reality it's far from that. Of course we had to guarantee there's no loop in the graph. Atoms had layout-after and layout-before edges to force the sorting order. Because nodes in the graph are for some reason doubly-linked, we had to guarantee that the forwarding and reversing edges are consistent. Also there's a notion of zero-length atom, and they are allowed to be at anywhere in the sort result (A -> B and A -> C are both allowed, if either B or C is zero-length, but if B and C are not empty, they are not allowed to be laid out out after A).</div><div><br></div><div>And the situation was even worse -- we also used other signals to order atoms, like from which file an atom is created. We sometimes use layout edges, and sometimes not. We had to guarantee that they are consistent.</div><div><br></div><div>If you wanted to update the graph, you had to be cautious not to break that consistency. It's not like "hey, we want to layout this thing after that, so just add layout-after between them!" It was actually much harder than that.</div><div><br></div><div>And what the LayoutPass was actually doing? It's just laying out atoms in the same order as in the command line! We constructed a graph, mutated that carefully not to break the consistency, ran series of complex graph algorithms, and what we got is the same layout as in the input.</div><div><br></div><div>That's apparently not the right balance.</div><div><br></div><div>I think what's clear now is forcing some layout using graph is actually complicated than one might think. Graph is much more flexible than plain linear total ordering. When we try to collapse the graph into an one-dimensional array in deterministic order, we need to make many subtle choices of how to order them. Conversely, we had to be careful when we construct the graph so that the graph is eventually reducible to a linear array.</div><div><br></div><div>I hope this describes why I don't want to restore the LayoutPass.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><font color="#888888">
<br>
Shankar Easwaran</font></span><div><div><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On Thu, Feb 12, 2015 at 10:44 AM, Shankar Easwaran <<a href="mailto:shankare@codeaurora.org" target="_blank">shankare@codeaurora.org</a>><br>
wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hi,<br>
<br>
It looks like the COFF reader creates an Alias atom by adding a<br>
kindLayoutAfter reference to the target atom. Now since the kindLayoutAfter<br>
passes are moved to machO how does it still work ?<br>
<br>
Does it work by chance because of ordinals ? I would think moving<br>
kindLayoutAfter references and having the LayoutPass would be a better<br>
choice.<br>
<br>
Shankar Easwaran<br>
<br>
--<br>
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted<br>
by the Linux Foundation<br>
<br>
<br>
</blockquote></blockquote>
<br>
<br>
-- <br>
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation<br>
<br>
</div></div></blockquote></div><br></div></div>