> -----Original Message-----
> From: Richard Biener <[email protected]>
> Sent: Saturday, March 21, 2026 03:33
> To: Robert Dubner <[email protected]>
> Cc: David Malcolm <[email protected]>; H. J. Lu <[email protected]>;
> [email protected]; James K. Lowden <[email protected]>
> Subject: Re: COBOL: Hoping for insight with middle-end computation time.
>
>
>
> > Am 21.03.2026 um 04:17 schrieb Robert Dubner <[email protected]>:
> >
> > Let's try another line of query.
> >
> > Maybe here are things I should be doing that I am not, or things that I
> > am
> > doing that I shouldn't.
> >
> > As described earlier, I created a version of the gcobol/cobol1 compiler
> > that
> > produced a stripped-down GENERIC that resulted in this repeated pattern
> > in
> > the -fdump-tree-original output.
> >
> > _intermediate__stack1_3.0.0.data = &_stack1_data_17.0;
> > _intermediate__stack1_3.0.0.capacity = 16;
> > _intermediate__stack1_3.0.0.allocated = 16;
> > _intermediate__stack1_3.0.0.offset = 0;
> > _intermediate__stack1_3.0.0.name = &"_stack1"[0];
> > _intermediate__stack1_3.0.0.picture = &""[0];
> > _intermediate__stack1_3.0.0.initial = 0B;
> > _intermediate__stack1_3.0.0.parent = 0B;
> > _intermediate__stack1_3.0.0.occurs_lower = 0;
> > _intermediate__stack1_3.0.0.occurs_upper = 0;
> > _intermediate__stack1_3.0.0.attr = 4160;
> > _intermediate__stack1_3.0.0.type = 6;
> > _intermediate__stack1_3.0.0.level = 0;
> > _intermediate__stack1_3.0.0.digits = 37;
> > _intermediate__stack1_3.0.0.rdigits = 0;
> > _intermediate__stack1_3.0.0.encoding = 1;
> > _intermediate__stack1_3.0.0.alphabet = 0;
> > D.311 = 0;
> > D.312 = 0;
> > _13 = D.311 & 18;
> > if (_13 != 0) goto <D.369>; else goto <D.370>;
> > <D.369>:
> > goto <D.371>;
> > <D.370>:
> > D.314 = 0;
> > ..pa_erf.19_14 = ..pa_erf;
> > D.312 = D.312 | ..pa_erf.19_14;
> > if (D.312 != 0) goto <D.373>; else goto <D.374>;
> > <D.373>:
> > goto <D.375>;
> > <D.374>:
> > <D.375>:
> > <D.371>:
> >
> > I have experimented with a C program until I came up with the same
> > .gimple:
> >
> > typedef struct strct
> > {
> > int a0; int a1; int a2; int a3; int a4; int a5; int a6; int a7; int a8;
> > int a9;
> > }strct;
> >
> > int
> > main(int argc, char **argv)
> > {
> > strct strc0{0,1,2,3,4,5,6,7,8,9};
> > int x0=0;
> > int y0=0;
> > int z0;
> > y0=x0&18;
> > if(y0!=0)
> > {}
> > else
> > {
> > z0=z0|pa_erf;
> > if(z0!=0)
> > {}
> > }
> > }
> >
> > Here is a side-by-side comparison of the repetitive .gimple generated by
> > the
> > two compilations:
> >
> > From the gcobol compilation From the xg++
> > compilation
>
> > -------- -------------------------
> > D.322 = 0; x3 = 0;
> > D.323 = 0; y3 = 0;
> > _17 = D.322 & 18; y3 = x3 & 18;
> > if (_17 != 0) goto <D.385>; else goto <D.386>; if (y3 != 0) goto
> > <D.3063>;
> > else goto <D.3064>;
> > <D.385>: <D.3063>:
> > goto <D.387>; goto <D.3065>;
> > <D.386>: <D.3064>:
> > D.324 = 0;
> > ..pa_erf.25_18 = ..pa_erf; pa_erf.3_4 = pa_erf;
> > D.323 = D.323 | ..pa_erf.25_18; z3 = z3 | pa_erf.3_4;
> > if (D.323 != 0) goto <D.389>; else goto <D.390>; if (z3 != 0) goto
> > <D.3066>;
> > else goto <D.3067>;
> > <D.389>: <D.3066>:
> > goto <D.391>; goto <D.3068>;
> > <D.390>: <D.3067>:
> > <D.391>: <D.3068>:
> > <D.387>: <D.3065>:
> > You can see they are essentially identical.
>
> Could it be your D.324 is global? Comparing the GIMPLE would tell.
> Possibly
> also BIND_EXPRs matter. -blocks dumps (some) also dump the scope tree.
>
> > However!
> >
> > 10,000 repeats of that code in the C++ program compiles in 1.36 seconds.
> > 20,000 repeats 3.18 seconds.
> > 40,000 repeats 7.92 seconds.
> >
> > 10,000 repeats in the COBOL program 16.76 seconds.
> > 20,000 repeats in the COBOL program 97.40 seconds.
> > 10,000 repeats in the COBOL program 551.56 seconds.
> >
> > Those times are -O0 compilations from the same build of gcc, invoked in
> > the
> > same ways.
> >
> > So. I am obviously doing something different in gcobol than whatever is
> > happening in xg++.
> >
> > The GENERIC I am creating is apparently about right. So, now I have to
> > ask
> > a question that I probably should have asked years ago:
> >
> > What do I need to do before creating the GENERIC for a function?
> >
> > What do I need to do afterward?
> >
> > Right now I don't think I am doing anything special before generating
> > any
> > GENERIC.
> >
> > At the end of a source code module, I call
> >
> > cgraph_node::finalize_function(function_decl, true);
> >
> > for each function I created in that module.
> >
> > What am I missing? What could I be doing, or not doing, that's causing
> > that
> > N-squared behavior?
>
> I don’t think you are doing anything obviously wrong. With cobol you are
> going
> to have a single large function which is somewhat special and more prone
> to run
> into such bugs where people were lazy and never imagined there’s so large
> data.
> We’ll have to fix those algorithms eventually.
>
> > I am feeling like somebody who has found a car, and figured out how to
> > get
> > it started and get it moving in first gear, but hasn't figured out how
> > to
> > get to any of the higher gears.
>
> There might be things you can do in the frontend to avoid running into
> such
> issues, but at least from the above it’s not obvious what that should be.
>
You folks have been giving me additional lines of investigation to follow,
and I will.
I have a C program and a COBOL program that produce essentially identical
output from -fdump-tree-gimple. I see that the outputs
from -fdump-tree-original are not very much alike:
>From C:
<<cleanup_point struct strctD.2994 strc1D.3033 = {.a0D.2984=0,
.a1D.2985=1, .a2D.2986=2, .a3D.2987=3, .a4D.2988=4, .a5D.2989=5,
.a6D.2990=6, .a7D.2991=7, .a8D.2992=8, .a9D.2993=9};>>;
<<cleanup_point intD.9 x1D.3034 = 0;>>;
<<cleanup_point intD.9 y1D.3035 = 0;>>;
intD.9 z1D.3036;
<<cleanup_point <<< Unknown tree: expr_stmt
(voidD.54) (y1D.3035 = x1D.3034 & 18) >>>>>;
if (y1D.3035 != 0)
{
}
else
{
<<cleanup_point <<< Unknown tree: expr_stmt
(voidD.54) (z1D.3036 = z1D.3036 | pa_erfD.2981) >>>>>;
if (z1D.3036 != 0)
{
}
}
And from GCOBOL
struct _intermediate__stack1_3.0.0 = {.data=&_stack1_data_17.0,
.capacity=16, .allocated=16, .offset=0, .name=&"_stack1"[0],
.picture=&""[0], .initial=0B, .parent=0B, .occurs_lower=0, .occurs_upper=0,
.attr=4160, .type=6, .level=0, .digits=37, .rdigits=0, .encoding=1,
.alphabet=0};
unsigned char _stack1_data_17.0[16];
signed int D.311 = 0;
signed int D.312 = 0;
(D.311 & 18) != 0 ? : unsigned long D.314;
D.314 = 0;
D.312 = D.312 | ..pa_erf;
D.312 != 0 ? : ;;
What I don't yet know is what's significant.
I'll keep looking. I'll try not to ask too many questions.
> Richard
>
> >
> >
