This is the mail archive of the 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: [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                           \
 : 0)

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.


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