[LTO] Run Argument Promotion before IPSCCP

[hazzlim]

Run ArgumentPromotion before IPSCCP in the LTO pipeline, to expose more constants to be propagated. We also run PostOrderFunctionAttrs to improve the information available to ArgumentPromotion's alias analysis, and SROA to clean up allocas.

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[hazzlim]

Due to the fact that Fortran passes most arguments by reference [1], Flang lowers constant arguments passed to function/subroutines as allocas + stores. We currently fail to propagate such constants during LTO in some cases, significantly impacting performance of some key benchmarks (e.g. SPEC CPU2017 bwaves). An FIR pass was added in #73829 to fix this, but is disabled by default due to portability concerns.

The core of the issue is that these constant values passed as pointers to local objects (allocas), which are promoted to scalar constants by Argument Promotion, are not able to be propagated by IPSCCP due to this running prior to Argument Promotion in the LTO pipeline.

This patch aims to address this by running Argument Promotion before IPSCCP in the LTO pipeline. We are then able to propagate such constants successfully. This gives a performance improvement of 20.1% in SPEC CPU2017 bwaves. This particular benchmark example is illustrative of the broader scope for improving Fortran code generation; for example Fortran array descriptors frequently generate structs filled with constants passed as pointers to functions, which are currently not propagated inter-procedurally in many cases at present.

The compile time cost of this change, measured by change in instruction counts for compiling CTMark:

Benchmark        | Change  |
-----------------+---------+
7zip             | +0.02%  |
Bullet           | +0.03%  |
ClamAV           | +0.04%  |
SPASS            | +0.03%  |
consumer-typeset | +0.06%  |
kimwitu++        | +0.22%  |
lencod           | +0.10%  |
mafft            | +0.09%  |
sqlite3          | +0.09%  |
tramp3d-v4       | -0.18%  |
-----------------+---------+
GEOMEAN          | 0.05%   |

An impact of this change is that some function arguments that would previously have been specialised by Function Specialization, which is currently only enabled for pointer arguments by default, are no longer specialised due to being promoted to literal constants. To mitigate this, PR #111162 enables specialising constant literal arguments by default for recursive functions. This has negligible impact on CTMark compile times (Geomean 0.00%) for both LTO and non-LTO pipelines.

[1] https://gcc.gnu.org/onlinedocs/gfortran/Argument-passing-conventions.html#Argument-passing-conventions-1

[aeubanks]

would be good to run this through https://llvm-compile-time-tracker.com/

have you considered moving IPSCCP later in the LTO pipeline?

[hazzlim]

would be good to run this through https://llvm-compile-time-tracker.com/

Agreed - my compile-time results are based on the methodology of llvm-compile-time-tracker, but it would be useful to get the full results. @nikic would you be able to do a run of this commit / add my fork https://github.com/hazzlim/llvm-project/ so that I can do so?

have you considered moving IPSCCP later in the LTO pipeline?

It was considered - based on the discussion on #96620 it seemed as though this would not be an acceptable approach, but perhaps considerations might be different in the full LTO pipeline?

[nikic]

I tested this a while ago but didn't post here: https://llvm-compile-time-tracker.com/compare.php?from=bf488ed6e1fbe4c494a1dc0dd199a3d03405784e&to=a4fe1ec912f4a2479218fc2d30ccbc8cf82cf782&stat=instructions:u It's indeed surprisingly cheap to run these extra passes.

A question I have here if this problem is somehow specific to LTO, or whether you just happen to be optimizing for LTO?

[hazzlim]

I tested this a while ago but didn't post here: https://llvm-compile-time-tracker.com/compare.php?from=bf488ed6e1fbe4c494a1dc0dd199a3d03405784e&to=a4fe1ec912f4a2479218fc2d30ccbc8cf82cf782&stat=instructions:u It's indeed surprisingly cheap to run these extra passes.

A question I have here if this problem is somehow specific to LTO, or whether you just happen to be optimizing for LTO?

Thanks for sharing these results, they seem mostly in line with what I have been seeing so that's good!

We just happened to be concentrating on improving the LTO pipeline here - I think that this would also be beneficial to non-LTO, provided the compile-time impact wasn't prohibitive there either.

Would it be preferred to make pipeline changes like this to LTO and non-LTO in separate PRs, or all in one go?

[hazzlim]

A question I have here if this problem is somehow specific to LTO, or whether you just happen to be optimizing for LTO?

It looks like it would be more expensive to do this non-LTO. The results I got for CTMark at O3 (non-LTO) on AArch64:

Benchmark        | Change  |
-----------------+---------+
7zip             | +0.11%  |
Bullet           | +0.21%  |
ClamAV           | +0.08%  |
SPASS            | +0.25%  |
consumer-typeset | +0.14%  |
kimwitu++        | +0.35%  |
lencod           | +0.01%  |
mafft            | +0.01%  |
sqlite3          | +0.11%  |
tramp3d-v4       | +0.28%  |
-----------------+---------+
GEOMEAN          | 0.15%   |

(For reference, this is the change I tested #111672)

[nikic]

@ronlieb Did you intend to merge this PR?

[hazzlim]

@ronlieb Did you intend to merge this PR?

+1. @nikic shall I perhaps revert this for now, as it has been merged without approval?

[nikic]

@ronlieb Did you intend to merge this PR?

+1. @nikic shall I perhaps revert this for now, as it has been merged without approval?

Yeah, I'd suggest reverting and opening a new PR (I don't think a merged PR can be reopened).

[ronlieb]

no i did not intend to merge that,
very sorry about that .

[ronlieb]

thanks for reverting it