<br><br><div class="gmail_quote">On Wed, Jan 30, 2013 at 1:56 PM, Quentin Colombet <span dir="ltr"><<a href="mailto:qcolombet@apple.com" target="_blank">qcolombet@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div>Hi Dan,</div><div><br></div>Thanks for the review.<div><br></div><div>In fact, I'm already aware of the problem you are reporting, i.e., instcombine disrupts the BFI pattern.</div>
<div>I'm not trying to fix this issue here.</div><div><br></div><div>Instead, I was trying to expose the kind of thing that can be achieved with the proposed hook using an in-tree target. </div><div><br></div><div>Unfortunately, I don't know enough the existing problems for in-tree targets to come with a better example, but I'm sure somebody else run into this kind of problems and the proposed hook could have ease their development.</div>
<div><br></div><div>What do you think of the proposed hook?</div></div></blockquote><div><br></div><div>In the abstract, it's counter to dagcombine's design. Dagcombine is designed to make use of canonicalization, in a similar fashion to instcombine. Opening up a mechanism to let targets make exceptions to this rule opens up a new kind of potential complexity. And, it adds yet another context to the already-known-to-be-confusing set of contexts in which target hooks can be called.</div>
<div><br></div><div>I don't think dagcombine's current design needs to remain fixed, however changing it really ought to be done with a clear motivation.</div><div><br></div><div>Dan</div><div><br></div></div>