On 06/07/2016 07:47 PM, Segher Boessenkool wrote:
This patch series introduces separate shrink-wrapping.
There are many things the prologue/epilogue of a function do, and most of
those things can be done independently. For example, most of the time,
for many targets, the save of callee-saved registers can be done later
than the "main" prologue.
Doing so helps quite a bit because the prologue is expensive for functions
that do not need everything it does done for every path through the
function; often, the hot paths do not need much at all, e.g. not those
things the prologue needs to do for the function to call other functions.
The first patch creates a command-line flag, some hooks, a status flag
("is this function wrapped separately", used by later passes), and
documentation for these things.
The next six patches are to prevent later passes from mishandling the
epilogue instructions that now appear before the epilogue: mostly, you
cannot do much to instructions with a REG_CFA_RESTORE note without
confusing dwarf2cfi. The cprop one is for prologue instructions.
Then, the main patch. And finally a patch for PowerPC that implements
separate wrapping for GPRs and LR.
Tested on powerpc64-linux (-m32/-m64, -mlra/-mno-lra), and on
powerpc64le-linux. Previous versions of this series also tested on
x86_64-linux.
Is this okay for trunk?
Segher
Segher Boessenkool (9):
separate shrink-wrap: New command-line flag, status flag, hooks, and doc
cfgcleanup: Don't confuse CFI when -fshrink-wrap-separate
dce: Don't dead-code delete separately wrapped restores
regrename: Don't rename restores
regrename: Don't run if function was separately shrink-wrapped
sel-sched: Don't mess with register restores
cprop: Leave RTX_FRAME_RELATED_P instructions alone
shrink-wrap: shrink-wrapping for separate concerns
rs6000: Separate shrink-wrapping
I'm going to largely let Bernd own the review on this. Just a few comments.
I certainly like the concept. My mental model is that parts of the
prologue might sink further than other parts of the prologue. It's not
an exact match, but I think it's a "close enough" mental model.
It looks like the "concerns" are all target defined and its the target's
responsibility to deal with dependencies between the "concerns". Right?
(BTW, I think "concerns" is a particularly poor name, perhaps
"reasons" would be better?).
Right now it looks like shrink_wrapped_separate essentially says "we did
something special here" -- while I don't think it's necessary for this
patch, describing what we did might be better. Essentially different
paths would have a set of prologue/epilogue attributes that apply to
that path.
This would be useful for things like cfgcleanup where you could join
noreturn calls more aggressively. Though this may not matter in any
significant way in practice.
There may be enough commonality that we can promote some "concerns" from
target dependent to target independent -- I've often wondered if we
could handle a fair amount of prologue/epilogue generation in target
independent ways. For simple targets, I wouldn't be terribly
surprised if all prologue/epilogue generation could be handled
generically and they'd get separate shrink-wrapping "for free". But
that's all blue-sky.
Jeff
