This is the mail archive of the
mailing list for the GCC project.
Re: MEM flags and stack temps
- To: law at redhat dot com
- Subject: Re: MEM flags and stack temps
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Wed, 15 Nov 2000 08:46:54 -0800
- Cc: kenner at vlsi1 dot ultra dot nyu dot edu, gcc at gcc dot gnu dot org
- Organization: CodeSourcery, LLC
- References: <10011151358.AA19694@vlsi1.ultra.nyu.edu><14558.974306257@upchuck>
>>>>> "law" == law <email@example.com> writes:
>> Any thoughts here?
law> I don't think it's a major problem. The only area where
law> (IMHO) it causes problems is the ability to share space for
law> large arrays in different (disjoint) scopes.
We went around on this a little bit once before. I remember a couple
of reasonable approaches:
- Move some of the sharing code into the front-ends/AST->RTL
In other words, just reuse the same DECLs in some cases.
- Treat stack slots like registers, and allocate them in a
"stack allocator". In other words, have (MEM (STACK_SLOT x))
for a while, and then resolve them to hard slots late
in the game.
I actually think both approaches are good ideas. The second is
appealing in that it helps blur the boundary between things that fit
in a machine register, and things that don't. In the long run, we
want to do CSE, etc., on structures too. If I write:
struct S a, b, c;
a.x = 3;
a.y = 4;
b = a;
c = b;
It would be great if the compiler knew that `c' was a struct whose `x'
field was `3' and whose `y' field was `4'.
Mark Mitchell firstname.lastname@example.org
CodeSourcery, LLC http://www.codesourcery.com