| Message ID | 4CA1E78C.1010802@net-b.de |
|---|---|
| State | New |
| Headers | show |
On 09/28/2010 06:03 AM, Tobias Burnus wrote: > For PARAMETERs in MODULEs which are of derived type or array-valued gfortran > creates a static variable. This patch ensures that no extra declaration is > generated for use associated parameters. > > If one runs the testcase (see PR) without patch, the result of > -fdump-tree-original-uid is: > > iD.1554 = paraD.1556[0]; > jD.1559 = paraD.1561[0]; > > with the patch, the result is: > iD.1513 = paraD.1510[0]; > jD.1516 = paraD.1510[0]; > > > Build on x86-64-linux and currently regtesting; if it succeeds: > OK for the trunk? > Yes, OK for trunk, Thanks for patch! Jerry
Tobias, Have you started addressed PR44945 at all? Or is this completely separate? Cheers Paul On Tue, Sep 28, 2010 at 3:32 PM, Jerry DeLisle <jvdelisle@frontier.com> wrote: > On 09/28/2010 06:03 AM, Tobias Burnus wrote: >> >> For PARAMETERs in MODULEs which are of derived type or array-valued >> gfortran >> creates a static variable. This patch ensures that no extra declaration is >> generated for use associated parameters. >> >> If one runs the testcase (see PR) without patch, the result of >> -fdump-tree-original-uid is: >> >> iD.1554 = paraD.1556[0]; >> jD.1559 = paraD.1561[0]; >> >> with the patch, the result is: >> iD.1513 = paraD.1510[0]; >> jD.1516 = paraD.1510[0]; >> >> >> Build on x86-64-linux and currently regtesting; if it succeeds: >> OK for the trunk? >> > > Yes, OK for trunk, Thanks for patch! > > Jerry >
On 09/28/2010 03:39 PM, Paul Richard Thomas wrote:
> Have you started addressed PR44945 at all? Or is this completely separate?
No, I have not looked at PR 44945. And yes, they are separate issues.
This PR is about using available gsym data also for PARAMETER while
44945 is about generating gsym data also when the MODULE is in a
different file.
I wonder which other decl issues are still lurking. As PR 45810 shows,
there are still performance differences for single-file programs
compiled w/ and w/o LTO. As Richard remarks, there is no reason that the
performance is different, which implies that there are still single-file
decl issues. (However, the example also shows that having the correct
decl does not necessarily make the program faster - actually, fatigue
[cf. PR] is 40% slower with LTO.)
Tobias
Tobias, > No, I have not looked at PR 44945. And yes, they are separate issues. This > PR is about using available gsym data also for PARAMETER while 44945 is > about generating gsym data also when the MODULE is in a different file. Ahhh yes, I looked at the PR and am now reminded - you are right. I even made a relatively relevant comment :-) > > I wonder which other decl issues are still lurking. As PR 45810 shows, there > are still performance differences for single-file programs compiled w/ and > w/o LTO. As Richard remarks, there is no reason that the performance is > different, which implies that there are still single-file decl issues. > (However, the example also shows that having the correct decl does not > necessarily make the program faster - actually, fatigue [cf. PR] is 40% > slower with LTO.) I didn't know that it is that bad. Why is that? Cheers Paul
Paul, On 09/28/2010 04:19 PM, Paul Richard Thomas wrote: > [PR 44945] > Ahhh yes, I looked at the PR and am now reminded - you are right. I > even made a relatively relevant comment :-) Are you going to work on that PR? >> (However, the example also shows that having the correct decl does not >> necessarily make the program faster - actually, fatigue [cf. PR] is 40% >> slower with LTO.) > I didn't know that it is that bad. Why is that? -fno-function-inline fixes it. The problem is seemingly that functions get inlined which shouldn't while the really hot function does not get inlined. Thus, the problem are the parameter settings for inlining which give up too soon (some count exceeds the limit) - and seemingly also some deeply nested loops are not recognized as being hot although they are. Like all inlining decisions, its highly heuristic and probably needs to have some extra tuning for Fortran, which tends to have deeply nested loops and does not have the "inline" attribute C has. Tobias
Tobias, > Are you going to work on that PR? > After stage 1.... being a regression, I think that's OK, is it not. My priorities are as we said: (i) CLASS arrays; (ii) (Re)allocate on assignment (if we can agree on option or not); and (iii) Allocatable component memory leaks. That latter can also come after stage 1 being a fairly important bug fix. Cheers Paul
2010-09-28 Tobias Burnus <burnus@net-b.de> PR fortran/45756 * trans-decl.c (gfc_get_symbol_decl): Use gsym for decl of module parameters. Index: gcc/fortran/trans-decl.c =================================================================== --- gcc/fortran/trans-decl.c (revision 164682) +++ gcc/fortran/trans-decl.c (working copy) @@ -1133,11 +1133,18 @@ gfc_get_symbol_decl (gfc_symbol * sym) if (sym->backend_decl) return sym->backend_decl; + /* Special case for array-valued named constants from intrinsic + procedures; those are inlined. */ + if (sym->attr.use_assoc && sym->from_intmod + && sym->attr.flavor == FL_PARAMETER) + intrinsic_array_parameter = true; + /* If use associated and whole file compilation, use the module declaration. */ if (gfc_option.flag_whole_file - && sym->attr.flavor == FL_VARIABLE - && sym->attr.use_assoc + && (sym->attr.flavor == FL_VARIABLE + || sym->attr.flavor == FL_PARAMETER) + && sym->attr.use_assoc && !intrinsic_array_parameter && sym->module) { gfc_gsymbol *gsym; @@ -1182,12 +1189,6 @@ gfc_get_symbol_decl (gfc_symbol * sym) if (sym->attr.intrinsic) internal_error ("intrinsic variable which isn't a procedure"); - /* Special case for array-valued named constants from intrinsic - procedures; those are inlined. */ - if (sym->attr.use_assoc && sym->from_intmod && sym->attr.dimension - && sym->attr.flavor == FL_PARAMETER) - intrinsic_array_parameter = true; - /* Create string length decl first so that they can be used in the type declaration. */ if (sym->ts.type == BT_CHARACTER)