This is the mail archive of the gcc@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]

Stack Abstraction !!


Hi Everyone,

This is with reference to the discussion thread
http://gcc.gnu.org/ml/gcc/2002-05/msg02749.html


I am planning to work on a method described below for stack abstration.
The intent is, I would like minimal changes to overall code and achieving
the purpose.There are some issues, though, for which your comments would
be useful.

Alexandre Oliva <aoliva@redhat.com>  Wrote:
>>On May 30, 2002, Zack Weinberg <zack@codesourcery.com> wrote:
>>Only if we stick with the existing, lame, way of representing stack
>>slots.  (mem:MODE (plus:P (reg:P sp) (const_int offset))) is a pain to
>>work with, yes.  Consider (stack:MODE slot) instead -- with slot being
>>akin to a pseudo-register number, and only one instance of any given
>>stack RTX.
>How is this different from plain pseudos?  At some point, we have to
>turn them into (mem (plus (reg sp) (const_int offset))), and reload is
>probably the best point.  It would be nice to defer the computation of
>the offset, but optimizing that can be very tricky

Somewhere in between above approaches is regarding a subset of the 
virtual registers as stack slots.This is possible, by defining something
like
FIRST_STACK_REGNUM. If register number in a pseudo is greater/less (in case
we
choose a -ve integer set) than FIRST_STACK_REGNUM it represents a stack
slot.

It would require lesser changes than say introducing new STACK rtx and is
probably
better than taking harsh assumption that all pseudos would be on the stack,
for pupose of making the access graph.

There are few issues though, the "addressof" expressions taken for stack
slots
may have to be retained till reload.The current assumption is that these
do not exist after cse.

Another issue possibly is representing structures and arrays would be
slightly
weird.At present they are represented as (mem:BLK fp+offset).In the new
scheme it will just be a some group of pseudos guarnteed to be contiguous.
Please let me know any additional points to take care of or,
any improvements.

Thanks to everyone who gave comments on the problem.

Best Regards,
	Naveen Sharma.


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