Re: Implement stack arrays even for unknown sizes

[Michael Matz <matz@suse.de>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1456 bytes --]

Hello,

On Mon, 11 Apr 2011, Steven Bosscher wrote:

> > Try this patch.  I've verified that capacita and nf work with it and
> > -march=native -ffast-math -funroll-loops -fstack-arrays -O3 .  In fact all
> > of polyhedron works for me on these flags.  (I've set a ulimit -s of
> > 512MB, but I don't know if such a large amount is required).
> 
> FWIW, I don't think it is reasonable to require ulimit -s to run
> polyhedron.

Actually only nf requires about 16MB of stack size, all other benchmarks 
run fine with 8MB (which is the default for my systems).  Note that ICC 
compiled binaries have the same behaviour and also require the user to set 
ulimits.

> Isn't there a way to put a maximum on the size of the arrays on stack, 
> e.g. -fstack-arrays-limit= or something like that?

Not without generating contorded code.  The problem is that these arrays 
are variable length, hence runtime tests would be required, branching to 
malloc or stack_save/alloca, and also for the deallocation side, requiring 
a flag for branching to free or stack_restore.  And as we use the variable 
length facilities this is actually not controllable in such a way, the 
frontend doesn't generate alloca calls at all.

Nope, it's either all or nothing, like with ICC.

> BTW why does trans-array need gimple.h?

create_tmp_var_name.  gfc_create_var_np doesn't take a location and at 
that point input_location is already at the end of file.


Ciao,
Michael.