Re: [PATCH] Possible fix for PR middle-end/6600?

[Jim Wilson <wilson at redhat dot com>]

>Even if the correct approach to PR mid/6600 is to fix instruction
>constraints in i960.md, this change should stop GCC ICEing where
>it currently does in the middle-end.

There isn't anything wrong with the constraints in i960.md.  It is the
mere existence of the movti pattern, and the default alignment of 16 for
strings, that causes the middle-end to try to create the 4-word constants.
The same problem could be reproduced on a few other targets if you put in
an explicit attribute align to get a 16-byte aligned string.

>The change is to distinguish the maximum number of bytes we can
>copy in a single instruction (MOVE_MAX_PIECES) from the maximum
>number of bytes that can be stored in a single instruction
>(STORE_MAX_PIECES).

It looks like you have a good idea here.  This does work fine for my i960
testcases.

I'd write the STORE_MAX_PIECES comment differently.  We need to check
HOST_WIDE_INT because of an internal gcc limitation, not because of limitations
with any store instruction on any target.  The key here is that all of the
effected functions can_store_by_pieces/clear_by_pieces/store_by_pieces are
only used when the source operand is a constant, and gcc has an internal
limit of 2*HOST_WIDEST_INT on the largest constant it can represent, so we
must limit the piece size to 2*HOST_WIDEST_INT.

There is the question of whether STORE_MAX_PIECES should be documented, but
since this is a macro that shouldn't be defined in any tm.h file, I don't
think it needs documentation.  I could be wrong here though.

I see only one minor flaw with this approach.  The change to store_by_pieces_1
limits clear_by_pieces to 2*HOST_WIDEST_INT, but the only constant used by
clear_by_pieces is 0, and 0 is const0_rtx regardless of the mode, so we
don't need the 2*HOST_WIDEST_INT restriction in this case.  However, I looked
at all of the existing ports, and the only 32-bit target with a movti pattern
that allows storing 0 is the i960, and the i960 is cheating here since it
just emits 4 word sized store zero instructions.  So we aren't losing anything
by limiting clear_by_pieces.  I think we can live with this minor flaw.

I think the patch is OK for gcc 3.2, with a more accurate STORE_MAX_PIECES
comment.

I noticed that can_store_by_pieces is missing an explanatory comment before
the function.  If you wanted to add that in too, that would be even better.

Jim