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>: > >
