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