On 09/11/2015 05:40 PM, Segher Boessenkool wrote:
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.
It can't move the prolog down (past) an insn that defines a register
that is only "used" in the prolog, since the prolog would then be
referencing the new value in the reg as opposed to what the value was
coming in to the function, this check is in requires_stack_frame_p().
The r0 case you mention is not a concern since r0 is first defined
before its use in the prolog.
>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?
Yes, that was part why I didn't submit it, didn't dig enough to convince
myself that was a safe thing, but thinking back that define_insn may
have only been used for prolog. Not that a specialized version still
wouldn't be a bad idea to prevent surprises down the road when it's
possibly used for non-prolog code that really does want all the CR's
listed. I agree that the whole non-volatile CR use issue should probably
be looked at. As you say, even if we aren't using them across calls
(which I'm guessing would be a low percentage if any), is it really
buying us much over just recomputing the compare.
-Pat
