[Patch,Fortran] PR 45756 Fix muliple-decl issue with PARAMETER

[Patch,Fortran] PR 45756 Fix muliple-decl issue with PARAMETER

[Tobias Burnus]

[-- Attachment #1: Type: text/plain, Size: 529 bytes --]

  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?

Tobias


[-- Attachment #2: gsym-parameter.diff --]
[-- Type: text/x-patch, Size: 1629 bytes --]

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)

Re: [Patch,Fortran] PR 45756 Fix muliple-decl issue with PARAMETER

[Jerry DeLisle]

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

Re: [Patch,Fortran] PR 45756 Fix muliple-decl issue with PARAMETER

[Paul Richard Thomas]

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
>



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy

Re: [Patch,Fortran] PR 45756 Fix muliple-decl issue with PARAMETER

[Tobias Burnus]

  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

Re: [Patch,Fortran] PR 45756 Fix muliple-decl issue with PARAMETER

[Paul Richard Thomas]

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

Re: [Patch,Fortran] PR 45756 Fix muliple-decl issue with PARAMETER

[Tobias Burnus]

  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

Re: [Patch,Fortran] PR 45756 Fix muliple-decl issue with PARAMETER

[Paul Richard Thomas]

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