For example, CPU2006/465.tonto and CPU2017/621.wrf_s,628.pop2_s benchmarks are now successfully compiling with the HLFIR lowering, while hitting unimplemeted TODOs with the FIR lowering. Some polymorphic types cases are also supported only with the HLFIR lowering. In our internal testing we see about 600 new tests passing with the HLFIR lowering, while the amount of tests that work with the FIR lowering and do not work with the HLFIR lowering is 21.
On the performance side, the HLFIR lowering also provides benefits such as allocating much smaller temporary arrays (e.g. in Polyhedron/test_fpu2 and CPU2017/527.cam), and applying more complex post-lowering “conflict” analysis for LHS and RHS parts of the array assignments (e.g. see @tblah’s work in ⚙ D157107 [flang][hlfir] add an optimized bufferization pass).
With all the work that has been put into the HLFIR lowering, I think we are almost ready to make the HLFIR lowering the default, but I would like to set several short-term goals that we have to achieve first. Please let me know if you want to add something in the list or something looks off to you.
C1: Keep Flang lowering covered with LIT tests as much as possible without delaying HLFIR enabling too much.
The HLFIR lowering is covered by LIT tests in flang/test/Lower/HLFIR. While there are fewer tests than for the FIR lowering (in flang/test/Lower), I think we may switch to the HLFIR lowering without migrating all the tests. The complete migration from flang/test/Lower to flang/test/Lower/HLFIR may be done after the switch. The quality of LIT testing will degrade in the menatime, but not much, given that the HLFIR lowering has decent amount of LIT tests as well.
I suppose, teams actively working on OpenMP will want to do the same for flang/test/Lower/OpenMP tests, so that the testing coverage does not degrade too much. I would consider this a blocker as well, but I have no resources to work on that. I would greatly appreciate help with this.
C2: Keep end-to-end testing in “good shape”:
As already mentioned, SPEC CPU 2000, 2006 and 2017 benchmarks compile and run successfully (w/o OpenMP) with the HLFIR lowering. We just need to keep it the same until we switch to the HLFIR lowering.
I do not have information about the SPEC CPU benchmarks or other tests that use OpenMP and won’t work with the HLFIR lowering. If you think we need to add some of them as blockers for the switch, please let me know.
Many thanks to @kiranchandramohan who has already started fixing bugs with HLFIR lowering for OpenMP!
P1: Keep performance on par with the FIR lowering (preliminary performance data (multiple tabs): HLFIR-perf.xlsx - Google Sheets).
I would like to keep SPEC CPU2006 and CPU2017 ref data set 1 copy performance on par with the FIR lowering, meaning we either achieve the same performance with the HLFIR lowering right away, or have exact explanation of the performance regressions not exceeding 25% and agree on the plans for fixing each of them. @tblah is pretty close on resolving some part of the huge regression of 548.exchange2 (other benchmarks will be improved as well). After that we should be able to do additional analysis and define our next steps. Please let me know if switching to the HLFIR lowering with pending performance regressions is not acceptable for your team.
I would like to have Polyhedron performance issues addressed the same way as SPEC CPU above (i.e. regressions of more than 25% regressions are not acceptable). Basically, we have to resolve inefficiencies in temporary arrays creation and array assignments. These issues will affect majority of Fortran programs, so switching to the HLFIR lowering with slowing down the rest of the world does not sound right.
These are all the checkboxes that I want to check before we switch. Please share your thoughts. Thank you!
Thanks @szakharin for sharing this RFC. Switch to HLFIR is exciting! Thanks to you, @tblah and @jeanPerier and others (@cabreraam, Jacob, …) who participated in the HLFIR work.
From our side the blockers are:
1.
We would like Spec2017 rate benchmarks to not degrade overall with the switch. At the moment, we see the following (with -Ofast -flto -mcpu=native) compared to FIR lowering as per results collected by @tblah. I think once the 554.roms benchmark is fixed, we are good to go.
Benchmark
Slowdown
Comment
503.bwaves
1.00
521.wrf
1.16
527.cam4
0.71
548.exchange2
1.18
549.fotonik3d
1.01
554.roms
1.56
Loop-versioning pass is not working with HLFIR lowering
Geometric Mean
1.07
BLAS/LAPACK should continue to work. We are in the process of checking where we are with this.
all OpenMP 1.1 features to continue to work after the switch. Currently there are issues with reduction, atomic, threadprivate support for common blocks.
No regressions with gfortran-testsuite, NPB, spec-2017 speed, spec-omp-2012, SNAP
Thank you for sharing your requirements, @kiranchandramohan! If you do not mind, I will add them into the list in the description, so that we have all the pieces together.
Patch 1: add a hidden -flang-deprecated-no-hlfir option to flang-new so that external users can revert to the current lowering if they face issues until any potential HLFIR regression is fixed. It will also be handy to transition remaining FIR tests that do not test HLFIR outputs.
Patch 2: update all these lowering tests to use bbc -hlfir=false and flang-deprecated-no-hlfir.
Patch 3: THE SWITCH. Set HLFIR lowering to be default in flang-new and bbc.
Step 2: The Wait and Clean (aiming for a duration of one LLVM release cycle).
Remove the -flang-experimental-hlfir (now redundant).
Have at least one LLVM release where HLFIR is enabled by default and -flang-deprecated-no-hlfir is accessible and in the meantime, remove all the no-hlfir version LIT tests that have already ported to HLFIR and transition the remaining no-hlfir LIT tests.
Debug any HLFIR regression reported by users
Step 3: The Removal (when step 2 is over)
Remove the -flang-deprecated-no-hlfir option in flang-new and -hlfir option in bbc.
Remove all usages of ConvertExpr.h interface inside Bridge.cpp and the rest of lowering.
Remove ConvertExpr.h/ ConvertExpr.cpp files and any helpers specific to it.
Is anyone familiar with the LLVM release schedule? It looks like the next big release will be LLVM 18. How can we check that this change will make it in?
Now that HLFIR is on by default, what interactions (if any) does this have with the rename of flang to flang-new? Last public discussion on this that I’m aware of made it sound like the switch to HLFIR by default would be the last checkbox for the switching the name:
(I guess one could nitpick that I’m equating “finish refactoring” with “switch on by default”; OTOH, once that happens, any further refactoring arguably just becomes regular development to progress the code-base.)
