[PATCH] Add a shrink-wrapping pass to improve the placement of prologue and epilogue.

Daniel Berlin dberlin at dberlin.org
Thu Apr 23 07:45:01 PDT 2015


On Wed, Apr 22, 2015 at 4:40 PM, Quentin Colombet <qcolombet at apple.com> wrote:
> Thanks for your feedback Daniel.
>
>> On Apr 22, 2015, at 4:24 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
>>
>> I was looking at the old version, but ...
>>
>> https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_26/lib/CodeGen/ShrinkWrapping.cpp
>>
>> This is essentially the Chow paper, but
>>
>> 1. The dataflow is not really expensive (It's O(N), the same as your
>> current algorithm). If it is, you should do it differently ;)  It can
>> be computed  really fast.  Definitely faster than computing
>> post-dominators.
>
> Post dominators are already available.
> Moreover, the data flow algorithm is much more expensive in space and, like I said, the handling of frequencies is a hack.
>
> Finally, implementing the Chow paper was never working, which make me believe that are some complexity not well understood here :).

Quite possibly :)

> Honestly, when I started this work, I looked into Chow’s paper and to me there is too much implementation details that are hidden under the carpet… the fact that the previous attempt to implement this never worked make me decide to take an alternative approach.

Sounds reasonable. I was just asking, since this is essentially "the
standard" (IE most compilers i know of implement some variant of it).

>
>>
>> 2. The chow paper handles multiple save/restore points :)
>
> Like I said, I do not think this is useful, at least for now. The problem with several save/restore points is that:
> - You will likely degrade the runtime for certain path. Chow has no solution for that IIRC.

Degrading some runtime is fine if you have profile info, of course.

> - You will increase the code size. That is a fact.

Sure.

>
> The bottom line is that I do not think this is worth paying the complexing (space/runtime) and frankly, if we want to go into the multiple points version, shrink-wrapping remains a black box and we can change its algorithm later and eventually resort on Chow's version.
>
> What do you think?

Sounds reasonable




More information about the llvm-commits mailing list