On 11/11/2015 11:10 AM, Alexandre Oliva wrote:
On Nov 10, 2015, Jeff Law <l...@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
