ppc and maybe also other cpu's stack problem

ppc and maybe also other cpu's stack problem

[Ralph Schmidt]

 Hello

Let's assume you have a lot constructs like this below gcc generates
*really* ugly code. It seems to grow the stack more and more and is
unable to see that the structs have no meaning outside of its lifetime.
It could simply make some kind of  stack union for these temp stack
extensions.
Do I miss something here or is there a cure for this problem in the
current gcc or in the coming version ?

Regards.

Little example:

void	func(void)
{

{
struct dumdidum big;
  DoSomething(&big);
}

{
struct dumdidum big;
  DoSomething(&big);
}

{
struct dumdidum big;
  DoSomething(&big);
}

}
---
Ralph Schmidt,laire@t-online.de(private),NextMail welcome 

Re: ppc and maybe also other cpu's stack problem

[Joern Rennecke]

> Do I miss something here or is there a cure for this problem in the
> current gcc or in the coming version ?

Have you tried -fno-strict-aliasing?

Re: ppc and maybe also other cpu's stack problem

[Ralph Schmidt]

You wrote:
> The following allocates two copies of struct dumdidum on stack:
> 
> > void    func(void)
> > {
> > { struct dumdidum big; DoSomething(&big); }
> > { struct dumdidum big; DoSomething(&big); }
> > }
> 
> 
> The reason is that preserve_temp_slots in function.c
> decrements the "level" of the struct when its address
> is taken, in case it is used as a result
> of a ({...}) construct (see comment on lines 1086..1093 of function.c
> 

I'll look at it.

> Obviously in this case no ({...}) construct is involved.
> There may be a simple fix for this simple case,
> but preseve_temp_slots is called from lots of places which was
> worrisome, and also some of the comments seemed at odds with the code.
> 

In reality it is a ({ construct and it's essentiell for inline os call macros
for me. Now imagine a lot of these calls in a function and suddenly
your stack runs amok and there's no other way to handle this.


> I suspect this code is mostly in limbo, awaiting
> a more comprehensively efficient way to allocate stack space.
> 

Indeed.

Regards

---
Ralph Schmidt,laire@t-online.de(private),NextMail welcome 

Re: ppc and maybe also other cpu's stack problem

[Thomas R. Truscott]

The following allocates two copies of struct dumdidum on stack:

> void    func(void)
> {
> { struct dumdidum big; DoSomething(&big); }
> { struct dumdidum big; DoSomething(&big); }
> }


The reason is that preserve_temp_slots in function.c
decrements the "level" of the struct when its address
is taken, in case it is used as a result
of a ({...}) construct (see comment on lines 1086..1093 of function.c

Obviously in this case no ({...}) construct is involved.
There may be a simple fix for this simple case,
but preseve_temp_slots is called from lots of places which was
worrisome, and also some of the comments seemed at odds with the code.

I suspect this code is mostly in limbo, awaiting
a more comprehensively efficient way to allocate stack space.

Tom Truscott