On Fri, Sep 11, 2015 at 05:06:47PM -0500, Pat Haugen wrote: > On 09/11/2015 02:49 PM, Segher Boessenkool wrote: > >On PowerPC, this enables shrink-wrapping of about 2%-3% more functions. > >I expected more, but in most cases this would help we cannot yet shrink- > >wrap because there are non-volatile registers used, often in the first > >block already. > I looked into shrink-wrapping earlier this year and noticed the same. I > tried expanding ira.c:split_live_ranges_for_shrink_wrap() to do a more > general live range splitting than the limited parm_reg->pseudo copies it > tries splitting now, but the splits ended up getting coalesced back > together and a non-volatile chosen. Unfortunately my digging got put on > the back burner and I haven't looked at it for a while.
It isn't an easy problem, lots of tradeoffs :-( RA is magic. > Another issue I saw for PowerPC that prevented shrink-wrapping was the > case where non-volatile CR's are used somewhere in the function. This > causes a 'mfcr' to be generated in the prolog to save the non-volatile > CR's, which currently lists all CR's as used. This kills shrink-wrapping > since the early exit test will define a CR which then fails the > shrink-wrap requirement of not defining a register used in the prolog. You mean it cannot put the prologue on an edge where some reg defined in the prologue is live? On PowerPC I see that mostly for r0 (it is used to move LR through), but it doesn't happen all that often -- it's the last of the volatile regs in the REG_ALLOC_ORDER already. I'll pay attention to the non-volatile CR fields, interesting. > I > tried a simple hack of just removing the volatile CR's from the > 'movesi_from_cr' define_insn and it solved the issue, but never > submitted a patch for just that piece. We probably need a specialised version for that. The other issue is, why do we use those CR fields at all? Are we saving them over calls (probably a bad tradeoff), or do we really want so many CR fields live? Segher
