This is the mail archive of the 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, PR 10474] Shedule pass_cprop_hardreg before pass_thread_prologue_and_epilogue

On 04/17/2013 09:49 AM, Martin Jambor wrote:

The reason why it helps so much is that before register allocation
there are instructions moving the value of actual arguments from
"originally hard" register (e.g. SI, DI, etc.) to a pseudo at the
beginning of each function.  When the argument is live across a
function call, the pseudo is likely to be assigned to a callee-saved
register and then also accessed from that register, even in the first
BB, making it require prologue, though it could be fetched from the
original one.  When we convert all uses (at least in the first BB) to
the original register, the preparatory stage of shrink wrapping is
often capable of moving the register moves to a later BB, thus
creating fast paths which do not require prologue and epilogue.
I noticed similar effects when looking at range splitting. Being able to move those calls into a deeper control level in the CFG would definitely be an improvement.

We believe this change in the pipeline should not bring about any
negative effects.  During gcc bootstrap, the number of instructions
changed by pass_cprop_hardreg dropped but by only 1.2%.  We have also
ran SPEC 2006 CPU benchmarks on recent Intel and AMD hardware and all
run time differences could be attributed to noise.  The changes in
binary sizes were also small:
Did anyone ponder just doing the hard register propagation on argument registers prior the prologue/epilogue handling, then the full blown propagation pass in its current location in the pipeline?

That would get you the benefit you're seeking and minimize other effects. Of course if you try that and get effectively the same results as moving the full propagation pass before prologue/epilogue handling then the complexity of only propagating argument registers early is clearly not needed and we'd probably want to go with your patch as-is.


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