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]

Re: MEM flags and stack temps


> 
>   - 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've done some experiments in this area - my approach was to always use
ADDRESSOF to generate stack slots in early pass, so I've got instantly
the ability to eliminate dead memory alocations entirely and the
ADDRESSOF pass can be definitly tweaked to be more smart about stack
frame allocations.

To get real benefits from such code we need safe way to eliminate dead
stores - current gcc does this partly because of Richard's patch and
with my hack it seemed to work well (producing shorter code).

Before Kenner's patch, the hack was enlarging code size slightly. I believe
that because of non-functional rtx-cost calculations.  After the patch,
code was slight win.

So perhaps ADDRESSOF is easy way to go.  BTW why it requires the pointer
to tree representation of type? It would be easier if it just contained
the size field and identifier at least from the RTL point of view.

Honza

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