This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Don't assume MEM_SIZE is always set in rs6000 adjacent_mem_locations (PR target/34225)
On Mon, Nov 26, 2007 at 10:25:42AM -0500, David Edelsohn wrote:
> I assumed because the testcase involved stack_tie that all of the
> failures involved stack_tie and the common parts of the compiler uniformly
> established MEM attrs. I don't disagree with current patch to protect the
> test, but I think the patch may be incomplete.
MEM attrs are computed usually from a tree decl node, if there is none,
often only very few are added. So size in MEM_ATTRS is missing very often,
but the MEM_SIZE macro is usually able to compute it from MEM's mode:
/* For a MEM rtx, the size in bytes of the MEM, if known, as an RTX that
is always a CONST_INT. */
#define MEM_SIZE(RTX) \
(MEM_ATTRS (RTX) != 0 ? MEM_ATTRS (RTX)->size \
: GET_MODE (RTX) != BLKmode ? GEN_INT (GET_MODE_SIZE (GET_MODE (RTX))) \
But in the stack tie case (or e.g. for VLAs etc.) where BLKmode doesn't
have a size, it just means the size is unknown.
> Because stack_tie is not a real instructon, I thought that the
> size could be the mode size. Also, because stack_tie it is not a real
> instruction, I expected that is_store_insn() should ignore it -- like all
> of the other byproducts of the GCC IR that unfortunately are treated as
> real instructions.
Well, stack_tie is presented as real instruction, the only thing the ppc
backend can see on it exceptional is zero length.
That said, rs6000_variable_issue and the various is_*_insn probably
should special case stack_tie, in most cases handle it the same way
as USE or CLOBBER. But it is not a correctness issue, but just something
to get better scheduling.