[Patch, fortran] PR20541 - allocatable components (TR15541)

[Paul Biggar]

As an aside, I'm starting to look at this sort of thing for escape
analysis for stack allocation. As is, I'm using alloca. However, I
believe that there is no specfic requirement to dynamically allocate
on the stack using alloca, and that doing so would hinder the use of
-fomit-frame-pointer?

I'm afraid I don't understand this patch too well, nor the problem
it's solving, but I'm wondering are you preallocating space on the
stack by increasing the frame size at compile time, or are you
fiddling with the frame pointer at run time, or some other way? If the
former, it seems this has benefits over using alloca.

Thanks
Paul

On 10/6/06, Tobias Schlüter <tobias.schlueter@physik.uni-muenchen.de> wrote:
> Paul Thomas <paulthomas2@wanadoo.fr> wrote on Fri, 06 Oct 2006:
> >> Out of curiousity, why didn't you use alloca instead of doing all
> >> this bookkeeping?  Maybe because you would have needed bookkeeping
> >> anyway  for the case where the allocatable component would have
> >> been >  -fmax-stack-var-size?  Or is there a simpler reason?
> >
> > Ignorance.
> >
> > Having looked at the spec. for alloca, you are right, we would have had
> > to branch for >  -fmax-stack-var-size; otherwise the warnings in the
> > gcc manual would hold good.  I will put a TODO in the code somewhere.
> >
> > It would simplify the code considerably - take a look for some of the
> > testcases!
>
> For the record, I don't think a size restriction on the allocated
> components would render a patch for the TR unacceptable.  Nor do I
> think that your patch is any less acceptable because you decided to
> manually allocate and deallocate the memory.
>
> OTOH I think it would be a good thing if you could estimate the
> probable savings in terms of code size and complexity a patch with
> alloca (or whatever one calls it when one means the portable
> equivalent) would bring.
>
> One thing that may render this more difficult than one expects, is
> that C has no notion of contained procedures, which may interfere with
> stack-based memory allocation.  I.e. __builtin_alloca may not be well
> tested in all circumstance that are interesting to us.  Maybe a
> middle-end person can weigh in on this?
>
> (As an aside, I wonder if we should allocate temporaries on the stack
> instead of the heap, as we do currently.  Going via a compiler builtin
> may be more transparent to the optimizers.)
>
> - Tobi
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
>
>


-- 
Paul Biggar
paul.biggar@gmail.com