This is the mail archive of the gcc-patches@gcc.gnu.org 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: [tree-ssa] PATCH to &&/|| gimplification



On Friday, May 30, 2003, at 10:47 AM, Richard Kenner wrote:


    Then we are talking at cross-purposes.  What exactly do you mean by
    memory tracking here?  Could you give me an example?

I'm talking about the content of MEM_EXPR, especially as used in
output_asm_operand_names.

So, for

struct r1 {int x;};
struct foo {int a; struct r1 f;};

int
bar (struct foo *p)
{
  return p->a + p->f.x;
}

on Alpha, we have:

	ldl $1,4($16)	 # <variable>.f.x, <variable>.f.x
	ldl $0,0($16)	 # <variable>.a, <variable>.a
	addl $0,$1,$0	 # <variable>.a, <variable>.b, tmp75
	ret $31,($26),1

The issue is how to preserve which field you are referencing if you
convert all COMPONENT_REF/ARRAY_REF nestings into address calculations.

You can always determine the field from the addressing info, except for unions.
If they weren't equivalent, we'd have problems :).


I also don't think the ability to output the above should stand in the way of *optimizing* the code.

Lastly, except for completely removed operations, we should be able to get back the MEM_EXPR's if necessary, though it may be a bit expensive.

--Dan


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