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


>>>>> Richard Kenner writes:

Richard> Are we only talking about the case when STRICT_ALIGNMENT is not defined?

	Yes.

Richard> If we're taking about that case, then I understand that the alignment might
Richard> be wrong.  I don't see the case where it matters, though: perhaps you can
Richard> be more precise on exactly why alignment matters on a machine when you are
Richard> saying it doesn't matter.

	It matters and has an effect exactly when SLOW_UNALIGNED_ACCESS is
defined.  If the memattrs alignment field adopts the MODE alignment, then
SLOW_UNALIGNED_ACCESS becomes moot for wide modes because their alignment
information will not be accurate.  GCC specifically provides a
SLOW_UNALIGNED_ACCESS macro because gradations of alignment other than
strict or non-strict do matter for selection of algorithms and
instructions.  "ACCESS" clearly implies memory operations.  If the
alignment information is not accurate, GCC cannot make an informed
selection using the one inquiry macro which has been made available.

	Is pointing out the SLOW_UNALIGNED_ACCESS macro sufficient?  Or do
you want me to analyze examples of where that macro is used when MEM_ALIGN
will now be wrong thereby causing GCC to make incorrect decisions?

Richard> Perhaps what you are saying is that #ifndef STRICT_ALIGNMENT, we should not
Richard> derive any alignment information from the mode.  I think that's right, and
Richard> would not object to making that change, but I still don't see how it would
Richard> affect anything.

	Yes, Jeff and I basically have been proposing that GCC not derive
any alignment from the MODE, unless STRICT_ALIGNMENT is defined.

Thanks, David


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