Re: Return value address

nicolas_capens@hotmail.com (c0d1f1ed) wrote
> ...
> 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!


    Almost every compiler does stack compression, eliminating allocation
of automatic variables wherever they are allocated to registers. I
don't know what would be the price of doing this for your compiler.
    If your compiler works with intermediate language, and only at the
end outputs the binary, there wouldn't be any problem. You'd just
update the stack offsets in the symbol table. If your compiler writes
the binary directly, it cannot do any global optimizations at all ...


    Michael

Return to the comp.compilers page.
Search the comp.compilers archives again.