Further debug tells me that 'no-force-blk' is set of fntype in assign_parms.
It looks like that the reason my struct argument is in BLKmode is
because our machine defines STRICT_ALIGNMENT 1. Changing this to
STRICT_ALIGNMENT 0, or adding a proper attribute(align()) to the
struct definition solves this.
Unfortunately I couldn't try our backend with a new compiler - yet -,
but I tried new compiler (4.8.1) with x86 backend and set
STRICT_ALIGNMENT to 1, but still got *good* code for above. Possibly
this is only a caveat of old compilers, being too conservative with
struct alignments?
When passing..
struct s64 {
unsigned int a;
unsigned int b;
};
..to a function, it looks like this tree always has BLKmode if
STRICT_ALIGNMENT is set for my (old-) compiler (3.2.3), and therefore
I am getting copies to the stack as mentioned above. In a machine with
64 bit registers supporting passing the struct in the arguments,
accessing argument b in a function then leads to a st/ld to/from the
stack as opposed to a simple shift.
However, the structure above passed in registers doesn't need BLKmode
as far as I can see.
Any ideas?
Thanks,
Regards,
Hendrik Greving
On Thu, Aug 15, 2013 at 10:46 AM, Hendrik Greving
<hendrik.greving.intel@xxxxxxxxx> wrote:
> I am debugging an old backend for a custom machine (sorry this is a
> question regarding a very old compiler, but I checked new sources and
> they look similar). The problem is the following. The backend does
> support passing struct function argument via registers. For a given
> function, I see that this is happening, but when accessing member of
> the struct, the entire struct is first copied to the stack before
> being accessed. This is happening in assign_parms, because the
> argument is BLKmode: See "If a BLKmode arrives in registers, copy it
> to a stack slot" comment in function.c:asign_parms. What causes it to
> be BLKmode?
>
> I debugged a x86 equivalent of the same version, and I see the same
> C-code leading to the struct being passed in DImode to assign_parms.
> Hence, I guess something in my backend must cause this.
>
> Any hints where I should look? I am seeing that if the parameters are
> going in DImode to assign_parms, this is much better for the code
> generated later, in some cases unnecessary copies to the stack are
> avoided.
>
> Thanks,
> Regards,
> Hendrik Greving
