Message ID | 4DBD2CBD.2040502@netcologne.de |
---|---|
State | New |
Headers | show |
Am 01.05.2011 11:49, schrieb Thomas Koenig: > Hello world, > > after Paul's fix for allocate on assignment (thanks Paul!), here is a > patch for the original test case from PR 22572, where the bounds of > the function are unknown at compile time. This uses an allocatable > temporary. Ping? Thomas
Am 03.05.2011 22:12, schrieb Thomas Koenig: > Am 01.05.2011 11:49, schrieb Thomas Koenig: >> Hello world, >> >> after Paul's fix for allocate on assignment (thanks Paul!), here is a >> patch for the original test case from PR 22572, where the bounds of >> the function are unknown at compile time. This uses an allocatable >> temporary. > > Ping? Ping**2? There's been a bit of offline discussion with Tobias regarding -Os and timings. At least for a simple test case, the patch made the resulting program shorter. As for timing, I would confidently expect that, even with -fstack-arrays, any useful function would take longer than a malloc()/free() pair. Thomas
On Fri, May 13, 2011 at 10:18:57PM +0200, Thomas Koenig wrote: > Am 03.05.2011 22:12, schrieb Thomas Koenig: > >Am 01.05.2011 11:49, schrieb Thomas Koenig: > >>Hello world, > >> > >>after Paul's fix for allocate on assignment (thanks Paul!), here is a > >>patch for the original test case from PR 22572, where the bounds of > >>the function are unknown at compile time. This uses an allocatable > >>temporary. > > > >Ping? > > Ping**2? > > There's been a bit of offline discussion with Tobias regarding -Os and > timings. At least for a simple test case, the patch made the resulting > program shorter. As for timing, I would confidently expect that, even > with -fstack-arrays, any useful function would take longer than a > malloc()/free() pair. > > Thomas Thomas, I can't find the diff. I read it over if you give me a pointer.
On 05/01/2011 02:49 AM, Thomas Koenig wrote: > Hello world, > > after Paul's fix for allocate on assignment (thanks Paul!), here is a > patch for the original test case from PR 22572, where the bounds of > the function are unknown at compile time. This uses an allocatable > temporary. > > In the long run, another option is to use interface mapping to evaluate > the bounds of intrinsics and explicit-shape functions. For this, it > would be necessary to write a front-end-only version of gfc_evaluate_now, which > would be complicated by the desire not to disturb common function elimination, > so I've put that on the back burner for now. > > Regression-tested. OK for trunk? > > Thomas OK and thanks for patch. Jerry
Hi Jerry, > On 05/01/2011 02:49 AM, Thomas Koenig wrote: >> Hello world, >> >> after Paul's fix for allocate on assignment (thanks Paul!), here is a >> patch for the original test case from PR 22572, where the bounds of >> the function are unknown at compile time. This uses an allocatable >> temporary. >> >> In the long run, another option is to use interface mapping to evaluate >> the bounds of intrinsics and explicit-shape functions. For this, it >> would be necessary to write a front-end-only version of >> gfc_evaluate_now, which >> would be complicated by the desire not to disturb common function >> elimination, >> so I've put that on the back burner for now. >> >> Regression-tested. OK for trunk? >> >> Thomas > OK and thanks for patch. > Waiting for Emacs... Sende fortran/ChangeLog Sende fortran/frontend-passes.c Sende testsuite/ChangeLog Hinzufügen testsuite/gfortran.dg/function_optimize_7.f90 Übertrage Daten .... Revision 173752 übertragen. Thanks for the review! I'll close the PR itself and add a new one for not using allocatable arrays. Thomas
Index: frontend-passes.c =================================================================== --- frontend-passes.c (Revision 173214) +++ frontend-passes.c (Arbeitskopie) @@ -152,11 +152,11 @@ cfe_register_funcs (gfc_expr **e, int *walk_subtre if ((*e)->ts.type == BT_CHARACTER) return 0; - /* If we don't know the shape at compile time, we do not create a temporary - variable to hold the intermediate result. FIXME: Change this later when - allocation on assignment works for intrinsics. */ + /* If we don't know the shape at compile time, we create an allocatable + temporary variable to hold the intermediate result, but only if + allocation on assignment is active. */ - if ((*e)->rank > 0 && (*e)->shape == NULL) + if ((*e)->rank > 0 && (*e)->shape == NULL && !gfc_option.flag_realloc_lhs) return 0; /* Skip the test for pure functions if -faggressive-function-elimination @@ -250,22 +250,38 @@ create_var (gfc_expr * e) symbol = symtree->n.sym; symbol->ts = e->ts; - symbol->as = gfc_get_array_spec (); - symbol->as->rank = e->rank; - symbol->as->type = AS_EXPLICIT; - for (i=0; i<e->rank; i++) + + if (e->rank > 0) { - gfc_expr *p, *q; + symbol->as = gfc_get_array_spec (); + symbol->as->rank = e->rank; + + if (e->shape == NULL) + { + /* We don't know the shape at compile time, so we use an + allocatable. */ + symbol->as->type = AS_DEFERRED; + symbol->attr.allocatable = 1; + } + else + { + symbol->as->type = AS_EXPLICIT; + /* Copy the shape. */ + for (i=0; i<e->rank; i++) + { + gfc_expr *p, *q; - p = gfc_get_constant_expr (BT_INTEGER, gfc_default_integer_kind, - &(e->where)); - mpz_set_si (p->value.integer, 1); - symbol->as->lower[i] = p; - - q = gfc_get_constant_expr (BT_INTEGER, gfc_index_integer_kind, - &(e->where)); - mpz_set (q->value.integer, e->shape[i]); - symbol->as->upper[i] = q; + p = gfc_get_constant_expr (BT_INTEGER, gfc_default_integer_kind, + &(e->where)); + mpz_set_si (p->value.integer, 1); + symbol->as->lower[i] = p; + + q = gfc_get_constant_expr (BT_INTEGER, gfc_index_integer_kind, + &(e->where)); + mpz_set (q->value.integer, e->shape[i]); + symbol->as->upper[i] = q; + } + } } symbol->attr.flavor = FL_VARIABLE;