On Sat, 2016-01-30 at 11:06 +0000, Richard Sandiford wrote:
> We need to be careful of examples like:
>
> struct __attribute__ ((aligned (8))) s { _Complex float x; };
> void foo (struct s *ptr, struct s val) { *ptr = val; }
>
> "x" gets SCmode, which has an alignment of 4. And it's OK for TYPE_MODE
> to have a smaller alignment than the type -- it's just not allowed to
> have a larger alignment (and even that restriction only applies because
> this is a STRICT_ALIGNMENT target). So the structure itself inherits
> this SCmode.
>
> The patch therefore changes how we handle foo() for -mabi=32 -msoft-float.
> Before the patch "val" is passed in $6 and $7. After the patch it's
> passed in $5 and $6. clang behaves like the unpatched GCC.
>
> If instead we use:
>
> struct __attribute__ ((aligned (8))) s { float x; float y; };
> void foo (struct s *ptr, struct s val) { *ptr = val; }
>
> then the structure has BLKmode and the alignment is honoured both before
> and after the patch.
>
> There's no real ABI reason for handling the two cases differently.
> The fact that one gets BLKmode and the other doesn't is down
> to GCC internals.
>
> We also have to be careful about the STRICT_ALIGNMENT thing.
> At the moment that's hard-coded to 1 for MIPS, but it's possible that
> it could become configurable in future, like it is for aarch64 and
> rs6000. !STRICT_ALIGNMENT allows TYPE_MODE to have a larger
> alignment than the type, so underaligned structures would get modes
> when they didn't previously. That would in turn change how they're
> passed as arguments.
>
> Thanks,
> Richard
Richard,
Can you explain why the GCC internals cause us to get SCmode instead of
BLKmode for the example with _Complex? I don't understand that. It
seems wrong to me and I don't understand where it is coming from.
Steve Ellcey
sell...@imgtec.com
