[PR64164] drop copyrename, integrate into expand

[Jeff Law]

On 11/11/2015 11:10 AM, Alexandre Oliva wrote:
> On Nov 10, 2015, Jeff Law <law@redhat.com> wrote:
>
>>> * function.c (assign_parm_setup_block): Right-shift
>>> upward-padded big-endian args when bypassing the stack slot.
>> Don't you need to check the value of BLOCK_REG_PADDING at runtime?
>> The padding is essentially allowed to vary.
>
> Well, yeah, it's the result of BLOCK_REG_PADDING that tells whether
> upward-padding occurred and shifting is required.
>
>> If you  look at the other places where BLOCK_REG_PADDING is used, it's
>> checked in a #ifdef, then again inside a if conditional.
>
> That's what I do in the patch too.
?  I don't see the runtime check in your patch.  I see a couple 
gcc_asserts, but no runtime check of BLOCK_REG_PADDING.

>
> That said, the initial conditions in the if/else-if/else chain for the
> no-larger-than-a-word case cover all of the non-BLOCK_REG_PADDING cases
> correctly, so that, if BLOCK_REG_PADDING is not defined, we can just
> skip the !MEM_P block altogether.  That's also the reason why we can go
> straight to shifting when we get there.
>
> I tried to document my reasoning in the comments, but maybe it was still
> too obscure?
Certainly seems that way.  Is it your assertion that the new code is 
what we want regardless of the *value* of REG_BLOCK_PADDING? 
Essentially meaning the check in the IF is covering both cases?

What am I missing here?

Jeff