|Return value address email@example.com (2004-09-07)|
|Re: Return value address firstname.lastname@example.org (Christoph Neubauer) (2004-09-08)|
|Re: Return value address email@example.com (2004-09-13)|
|Re: Return value address Nicola.Musatti@ObjectWay.it (2004-09-14)|
|Re: Return value address firstname.lastname@example.org (Christoph Neubauer) (2004-09-21)|
|Re: Return value address email@example.com (2004-09-21)|
|Date:||7 Sep 2004 23:58:03 -0400|
|Posted-Date:||07 Sep 2004 23:58:03 EDT|
I'm writing an optimizing x86 JIT compiler back-end, and I've run into
a little problem. Local variables get allocated on the stack, but
their values are kept in registers as much as possible, using
linear-scan register allocation. Now, return values are allocated on
the stack as well, to allow agressive inlining and optimize them as
any other variable. This causes problems with the stack management...
I'll illustrate with an example:
int foo(int x, int y)
return x + y;
It's obvious that this function is ideal for inlining. It would
translate into pseudo x86 code like this:
mov t, x
add t, y
mov r, t
Here, t respresents a temporary variable to hold the sum, and r is the
return value. Assuming x is stored at stack offset 0, and y at offset
4, t would be allocated at offset 8, and r at 12. The register
allocator makes sure that the actual calculations happen with
registers. The optimizer (which is actually before my register
allocator) optimizes redundant copy operations (the last mov).
This looks easy, but there's a caveat. The t variable is created
temporarily and deleted at the end of this function. So it is 'popped'
of the stack. However, r is still allocated on the stack at offset 12,
not 8! So the next allocation will take the stack top, which is at
offset 12, and assign the same position to this new variable as my
return value. Obviously this causes trouble...
So, has anyone ever worked on a similar project? My software is a bit
non-classical in the sense that everything is done linearly (no
lookahead). This makes it extremely fast but things like this are not
easy to solve. All ideas highly appreciated!
Return to the
Search the comp.compilers archives again.