<div dir="ltr"><br><div class="gmail_extra">Hey Chris,</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 1, 2017 at 11:20 AM, Chris Bieneman via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</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"><br><div><span class=""><blockquote type="cite"><div>On Aug 1, 2017, at 1:07 AM, Andrey Bokhanko via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="m_3691429525986146916Apple-interchange-newline"><div><div dir="ltr"><div><div><div><div>All,<br><br>+1 to what Mehdi said.<br><br></div><div>It's a fair concern to question whatever we need yet another Outlining pass. I believe this concern has been cleared by River -- both with theoretical arguments and practical data (benchmark numbers).<br></div></div></div></div></div></div></blockquote><div><br></div></span><div>I want to point out that River has not provided full raw benchmark data, he has provided summarized data. Also, as a community of engineers I think theoretical arguments are dangerous to accept. The community has also not been presented with sufficient information to understand some of the differences between the numbers for the IR outliner and MIR outliner. </div></div></div></blockquote><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><div><br></div><div>Since the two are using very similar algorithms for detecting outlining candidates I would expect the numbers to be very similar, however in many cases they are not. I think understanding those differences and comparing them will help inform whether or not the IR outliner needs changes before being integrated to LLVM. I'm not advocating that we shouldn't take the IR outliner (in fact I think IR outlining is an interesting optimization). I'm advocating that we should understand and explore how this pass will fit into LLVM today and in the future.</div></div></div></blockquote><div><br></div><div>You *sound* very frustrated by the process here, but as a person with no dog in this fight, i'm kind of struggling to understand why.</div><div>It seems a very similar process to what we've done in other situations.   </div><div><br></div><div>If i may suggest: I think, regardless of the outcome of this thread, it may be worth you taking a step back, abstracting the set of issues you are seeing a bit, and starting a thread about it (with concrete examples, but hopefully without blame!).</div><div><br></div><div>Because if you (and others!) are seeing a broken process here, it definitely should be looked at.</div><div>But in some ways, i don't think we're going to be able to intertwine "process fixing" with this particular patch.   IME, that rarely works very well.</div><div>(But i'll butt out if you really want to try :P)</div><div><br></div><div><br></div><div><br></div><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><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div><div><div><div><br></div><div>Jessica's pipeline proposal is completely orthogonal. It's not fair to request River to implement / fit into what she suggested. Sure, it's a valid topic to discuss -- but yet completely orthogonal one. If anything, accepting River's implementation would enable us to do experiments / developments like pipeline changes of this ilk!<br></div></div></div></div></div></div></blockquote><div><br></div></span><div>I completely disagree. When considering accepting a new pass to LLVM it is completely reasonable, appropriate, and not orthogonal to consider how that pass would interact with other existing passes. Also, given that in the past we've requested much more of contributors trying to make large contributions (see the many SPIR-V discussions) I think it is totally fair to request River consider Jessica's suggestion, and if the community felt that was the right approach it would be fair to request him to implement it.</div></div></div></blockquote><div><br></div><div>I think this is very much a matter of degree: IE i think there is a continuum of stuff people would consider reasonable and not.</div><div> <br></div><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><div><br></div><div>Please keep in mind, every new piece of functionality added to LLVM adds a maintenance burden on the community. If we are going to accept the burden of maintaining a new pass, it is reasonable for us, as a community, to request that the pass be engineered in a way that will make it worth that maintenance.</div><div><br></div><div>Further, I am incredibly frustrated by the fact that people in this thread seem intent on squashing relevant technical discussions or turning them into combative arguments. There is nothing wrong with asking technical questions on an RFC, and we should be encouraging cooperative discussions of present and future implications of all proposals.</div></div></div></blockquote><div><br></div><div>This sounds right, as long as we all agree that all processes much reach finality at some point.  IE at some point a decision has to be made, and it can't be "after we've exhaustively attempted everything" <br></div><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><div></div><div>-Chris</div></div></div></blockquote></div></div></div>