This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Unaligned block moves and MEM_ALIGN re-broken


	We are repeating the same discussion that occurred in November.

http://gcc.gnu.org/ml/gcc/2001-11/msg00377.html

When I said: "I don't think the type should have been layed out as DImode
if the alignment didn't support that."

You said: "I think that GCC should choose an integral mode for a struct as
often as it can since that will allow objects of that type to be put in
registers."

	We do want structs that fit within a register to be manipulated
within a register, so that forces the choice, if we do not want to
introduce performance regressions.

	STRICT_ALIGNMENT is too coarse-grained a switch and inappropriate
for PowerPC Big-Endian mode.  I and many other people have told you this
before during the previous discussion.  STRICT_ALIGNMENT also alters the
ABI which is unacceptable.  GCC much conform to the target ABI and target
processor; it cannot force the target to bend to its needs.
STRICT_ALIGNMENT is not a productive course of discussion.  Period.

	My view of the real problem is that GCC is using STRICT_ALIGNMENT
in multiple contexts where it has different purposes.  We already decided
before that we wants structs in registers if they fit, so the the structs
must have modes reflecting target register modes other than BLKmode.  We
cannot use SLOW_UNALIGNED_ACCESS in place of STRICT_ALIGNMENT in
stor-layout.c because that will prevent structs from being manipulated in
registers.

	With your change, the GCC backend now has incorrect information
about the alignment of memory.  Because of that inaccurate information it
chooses incorrect algorithms and incorrect instructions for operating on
the memory it assumes to be sufficiently aligned.  If MODE implies
alignment, then there should be no need for supplemental alignment
information about MEMs other than BLKmode.  Either MEM_ALIGN is redundant
or it is not.

	Your change caused a performance regression on PowerPC.  If you
want MODE to imply alignment, then you must correct all backends which
were not written to conform with this newly invented semantic and must
correct any performance regressions which result.  Otherwise, MEM_ALIGN is
not redundant and must reflect the true known alignment of the TYPE, not
the alignment of the MODE.

	The minimal work-around is that the PowerPC port needs some way of
determining the true alignment if the MEM_ALIGN information is no longer
accurate.

David


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]