Re: STRICT_ALIGNMENT is too strict for m68k

[Kamil Iskra <kamil at dwd dot interkom dot pl>]

On Sat, 16 May 1998, Richard Henderson wrote:

> > > Changing the value of STRICT_ALIGNMENT changes the ABI.  In particular,
> > > it will affect structure layout.
> > Is that really so? According to tm.texi:
> Yes.  See how it affects the alignment (and thus the size) of a 
> structure in layout_record.

I see. Thanks for the explanation.

However, I spent some time today on this part of stor-layout.c trying to
understand it and build a testcase that would prove my patch wrong and so
far I failed.

We are talking about the following code from stor-layout.c:layout_type,
right?


  /* Normally, use the alignment corresponding to the mode chosen.
     However, where strict alignment is not required, avoid
     over-aligning structures, since most compilers do not do this
     alignment.  */

  if (TYPE_MODE (type) != BLKmode && TYPE_MODE (type) != VOIDmode
      && (STRICT_ALIGNMENT
	  || (TREE_CODE (type) != RECORD_TYPE && TREE_CODE (type) != UNION_TYPE
	      && TREE_CODE (type) != QUAL_UNION_TYPE
	      && TREE_CODE (type) != ARRAY_TYPE)))
    TYPE_ALIGN (type) = GET_MODE_ALIGNMENT (TYPE_MODE (type));


I don't think this code applies to over-aligning structures, at least not
on m68k.

Many m68k targets define STRUCTURE_SIZE_BOUNDARY to be equal to
BIGGEST_ALIGNMENT. This means that structures are always maximally
aligned, thus the above code cannot over-align them.

Even if STRUCTURE_SIZE_BOUNDARY is not defined, the following code from
layout_type, case RECORD_TYPE takes care of things:


	  /* If structure's known alignment is less than
	     what the scalar mode would need, and it matters,
	     then stick with BLKmode.  */
	  if (STRICT_ALIGNMENT
	      && ! (TYPE_ALIGN (type) >= BIGGEST_ALIGNMENT
		    || (TYPE_ALIGN (type)
			>= TREE_INT_CST_LOW (TYPE_SIZE (type)))))
	    {
	      if (TYPE_MODE (type) != BLKmode)
		/* If this is the only reason this type is BLKmode,
		   then don't force containing types to be BLKmode.  */
		TYPE_NO_FORCE_BLK (type) = 1;
	      TYPE_MODE (type) = BLKmode;
	    }


Combined with the first code fragment shown, it prevents structures from
over-aligning.

I begin to wonder if the second code fragment doesn't make the first one
redundant, at least in the case of RECORD_TYPE. But then, some targets
might have some unusual alignment requirements, where alignment does not
correspond to the type size or sth. Still, this is not the case with m68k,
where chars are 8-bit aligned and everything else is 16-bit (or, on some
subtargets, 32-bit for types >= 32bits). Therefore, I still think that my
patch is OK.

> One might argue, given its description
> in tm.texi, that this was wrong.  Alternately, tm.texi was simply
> not updated properly.

Yeah, tm.texi clearly does not correspond to the actual behavior of
STRICT_ALIGNMENT and is misleading. I guess we are too late by at least a
few years to change the behavior of STRICT_ALIGNMENT, so I do agree with
another mail of yours that a new macro, equal to STRICT_ALIGNMENT by
default, ought to be defined.

/ Kamil Iskra    AmigaOS  Linux/i386  Linux/m68k               \
| GeekGadgets GCC maintainer   UNIX system administrator       |
| iskra@student.uci.agh.edu.pl  kiskra@ernie.icslab.agh.edu.pl |
\ kamil@dwd.interkom.pl   http://student.uci.agh.edu.pl/~iskra /