On 07/13/2017 04:54 PM, Jeff Law wrote:
> On 07/12/2017 07:44 PM, Segher Boessenkool wrote:
>> I don't really see why this is so complicated, and why the rs6000
>> target changes (a later patch) are so big. Why isn't it just simple
>> patches to allocate_stack (and the prologue thing), that check the
>> flag and if it is set do some probes?
> Yea. I wasn't happy with the size of the rs6000 patches either, which I
> mentioned at some point :-) Some of the complexity is making sure we
> keep the backchain pointer correct and trying to do so as efficiently as
> possible. But there's too much conceptual code duplication.
>
> Essentially the code shows up 3 times in slightly different forms.
So in the V2 patch the PPC code is somewhat cleaner. It's inherently
going to be more complex than the other ports because it has to handle
dynamic allocation and probing on its own rather than relying on the
generic code.
What I've done is broken out a few helper functions in that generic code
that the ppc backend can use. There's helpers that compute the key
information we need (rounded size, last address, residual allocation,
etc), code to emit the start of the loop and code to emit the end of the
loop.
So the PPC dynamic code in rs6000.md looks something like this now
compute_data (...)
if (loop needed)
{
emit_loop_start (...);
ppc magic to allocate & probe a stack page
emit_loop_end (...);
}
if (residuals)
{
fix operands[1] and let the rest of the expander run
}
Ideally those three helpers could be used by other ports that have
backend specific expanders to handle dynamic stack allocations.
Jeff
