assign_parms, arguments in BLKmode

Hendrik Greving
Thu Aug 15 18:53:00 GMT 2013

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;
}; 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?

Hendrik Greving

On Thu, Aug 15, 2013 at 10:46 AM, Hendrik Greving
<> 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

More information about the Gcc-help mailing list