Re: COBOL: Hoping for insight with middle-end computation time.

On Thu, 2026-03-19 at 18:22 -0500, Robert Dubner wrote:
> It happens that COBOL has the COMPUTE statement.  It takes the form
> of,
> for example, COMPUTE DDD = AAA + BBB.
> 
> We implement that by creating a temporary variable, using that as the
> target of an addition of AAA and BBB, and then doing an assignment to
> DDD.
> (Recall that COBOL variables can be quite complex, so we are a long
> way
> from being able to do this with an ADD_EXPR.)
> 
> We have determined that the way I've been producing GENERIC for that
> results in N-squared computation time somewhere in the middle end.
> 
> I have been tearing my hair out trying to figure out what's causing
> that
> N-squared behavior.  I commented away the assignment, and I got rid
> of the
> arithmetic.  All that's left is the creation of the temporary, and
> some IF
> statements that are generated to test for errors along the way of the
> computation.  (COBOL has a very rich error-detection and
> exception-generating facility.
> 
> The remaining GIMPLE for a single iteration (as shown by
> -fdump-tree-gimple) is shown below.  The "phase opt and generate"
> times
> for repetitions of that GIMPLE are shown here:
> 
>         phase opt	   Factor
> Repeats & generate
>   1,000       0.17	
>   2,000       0.49      2.9
>   4,000       1.55      3.2
>   8,000       7.56      4.9
>  16,000      49.31      6.5
>  32,000     281.29      5.7
> 
> I have been struggling with this for days.  Is there an explanation
> for
> why the following GIMPLE is resulting in that N-squared behavior?

Hi Bob.  You cite the overall "phase opt and generate" times, but no
data on how this is spread across the various optimization passes.
  
What's the output of -ftime-report on your workload?

In particular, are there any specific passes that are responsible for
the growth in time (and thus where we can pinpoint a bug), or is the
time evenly distributed across all of them?

Sorry if this is a silly question
Dave


> 
> I agree that the conditionals are a bit convoluted, and Jim and I are
> working to do COMPUTE in a much improved way.  But I still feel a
> need to
> understand what's going on!
> 
> Thanks so much for any insight into what might be happening here.
> 
>       _intermediate__stack501_503.0.0.data = &_stack501_data_517.0;
>       _intermediate__stack501_503.0.0.capacity = 16;
>       _intermediate__stack501_503.0.0.allocated = 16;
>       _intermediate__stack501_503.0.0.offset = 0;
>       _intermediate__stack501_503.0.0.name = &"_stack501"[0];
>       _intermediate__stack501_503.0.0.picture = &""[0];
>       _intermediate__stack501_503.0.0.initial = 0B;
>       _intermediate__stack501_503.0.0.parent = 0B;
>       _intermediate__stack501_503.0.0.occurs_lower = 0;
>       _intermediate__stack501_503.0.0.occurs_upper = 0;
>       _intermediate__stack501_503.0.0.attr = 4160;
>       _intermediate__stack501_503.0.0.type = 6;
>       _intermediate__stack501_503.0.0.level = 0;
>       _intermediate__stack501_503.0.0.digits = 37;
>       _intermediate__stack501_503.0.0.rdigits = 0;
>       _intermediate__stack501_503.0.0.encoding = 1;
>       _intermediate__stack501_503.0.0.alphabet = 0;
>       D.2812 = 0;
>       D.2813 = 0;
>       _1013 = D.2812 & 18;
>       if (_1013 != 0) goto <D.9353>; else goto <D.9354>;
>       <D.9353>:
>       goto <D.9355>;
>       <D.9354>:
>       D.2814 = 0;
>       ..pa_erf.1519_1014 = ..pa_erf;
>       D.2813 = D.2813 | ..pa_erf.1519_1014;
>       if (D.2813 != 0) goto <D.9357>; else goto <D.9358>;
>       <D.9357>:
>       goto <D.9359>;
>       <D.9358>:
>       <D.9359>:
>       <D.9355>:
> 
>