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 12:19 AM, Segher Boessenkool wrote:
Thanks for looking at the patches Jeff.

On Thu, Sep 08, 2016 at 10:28:59AM -0600, Jeff Law wrote:
Right.  Essentially Segher's patch introduces the concept of prologue
components that are independent of each other and which can be
shrink-wrapped separately.  The degree of independence is highly target
specific, of course.

There can be dependencies as well (e.g. a save to the frame requires that
frame to be set up already), but the current patches have no way to
describe such dependencies.  I haven't found a good way to describe the
dependencies yet.  Finding a good balance between general and useful isn't
easy, as usual.
Right. I over-simplified a bit here. Some dependencies can be handled via the hooks in the target files. I think what we've got is sufficient for now -- we'll have a much clearer picture of weak spots in the design if/when someone enables separate shrink wrapping for another target. Until then, I think we're OK.


I think one of the questions (and I haven't looked through the whole
thread yet to see if it's answered) is why the basic shrink-wrapping
algorithm can't be applied to each of the prologue components -- though
you may have answered it with your loop example below.

You get code size explosion with the "basic" algorithm.  And a lot of
that isn't really worth it: avoiding the whole prologue/epilogue is
usually worth copying some blocks for, but avoiding just a single register
save/restore pair?  More doubtful.
Understood. We have similar balancing problems elsewhere. How much duplication should we allow to expose a CSE or eliminate a conditional jump on a path through the CFG.

So I think sticking with this as a design decision makes sense -- does it impact the issue around running a particular component's prologue more than once?


Thanks.  I'd been wondering about when it'd be useful to push prologue
code into a loop nest when I saw the patches fly by, but didn't think
about it too much.  I haven't looked at the shrink-wrapping literature
in years, but I don't recall it having any concept that there were cases
where sinking into a loop nest was profitable.

It isn't common, but it does happen.  If you use a proper cost metric
based on executiuon frequency with some algorithm then that algorithm will
naturally avoid placing *logues into loops.
Right and the cases where it's placing them into loops it's going to be doing so on paths that are unlikely executed within the loop. ISTM that using frequencies is a significant step forward over the older placement algorithms in this space (which IIRC were structured as simple dataflow solvers) -- with the added advantage that if we have profiling data we can make better decisions.

Does this impact the compile time computation complexity issue that was raised elsewhere?

jeff


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