[llvm-dev] [RFC] Add IR level interprocedural outliner for code size.

[Daniel Berlin via llvm-dev]

Hey Chris,

On Tue, Aug 1, 2017 at 11:20 AM, Chris Bieneman via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
> On Aug 1, 2017, at 1:07 AM, Andrey Bokhanko via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> All,
>
> +1 to what Mehdi said.
>
> 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).
>
>
> 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.
>

> 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.
>

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.
It seems a very similar process to what we've done in other situations.

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!).

Because if you (and others!) are seeing a broken process here, it
definitely should be looked at.
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.
(But i'll butt out if you really want to try :P)




>
> 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!
>
>
> 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.
>

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.


>
> 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.
>
> 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.
>

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"

> -Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170801/3e7cc706/attachment.html>