Unaligned block moves and MEM_ALIGN re-broken
Richard Kenner
kenner@vlsi1.ultra.nyu.edu
Fri Jan 25 15:34:00 GMT 2002
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."
Right. "as often as it can" meant "consistent with alignment requirements".
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.
Chosing a default from the mode is just an optimization to avoid having
an attribute structure in the default cases.
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
What "newly invented semantic"?
Are we only talking about the case when STRICT_ALIGNMENT is not defined?
If we're taking about that case, then I understand that the alignment might
be wrong. I don't see the case where it matters, though: perhaps you can
be more precise on exactly why alignment matters on a machine when you are
saying it doesn't matter.
If we are *not* talking about that case, then please explain what's wrong.
Perhaps what you are saying is that #ifndef STRICT_ALIGNMENT, we should not
derive any alignment information from the mode. I think that's right, and
would not object to making that change, but I still don't see how it would
affect anything.
More information about the Gcc
mailing list