This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v2 0/9] Separate shrink-wrapping


On 09/09/2016 09:28 AM, Segher Boessenkool wrote:
Segher's code essentially allows individual components of the prologue
to sink to different points within the function rather than forcing the
prologue to be sunk as an atomic unit.

It also allows prologue an epilogue components to be placed in multiple
places,
Right.  I need to keep that in the forefront of my mind.



and even allows them to be executed more than once, if that is
cheaper.
This is the part that I'm still struggling with.


The full-prologue algorithm makes as many blocks run without prologue as
possible, by duplicating blocks where that helps.  If you do this for
every component you can and up with 2**40 blocks for just 40 components,

Ok, so why wouldn't we use the existing code with the duplication part
disabled? That's a later addition anyway and isn't necessary to do
shrink-wrapping in the first place.
I think the concern here is the balance between code explosion and the
runtime gains.

The code explosion can be terrible if you have only a few components,
already.  The runtime gains are not so great either.  Here's a simple
example, showing part of a cfg, the exits to the right are calls to
abort and need some prologue component:

|
1
|\
| \
2  X1
|\
| \
|  X2
|
  3

With the "old" algorithm, you need to place the prologue at 1 (because
you can only have one), and then the fall-through path also necessarily
gets that component's prologue.  With the "separate" algorithm, the
component prologues can be placed at X1 and X2 instead (and that will
most likely be cheapest according to the cost model, too).
Thanks. That really helps highlight some of the key differences between the old and new model.



You can also put this in a loop.  I'll try to make a simple example
with that.
That would be great.  And a case where they execute more than once too.

Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]