Perhaps this question is premature, but is this still aiming for inclusion in LLVM 17? It sounds like it would affect our (currently still WIP) packaging & redistribution of flang quite a lot. From a high-level view, the approach looks great (I like the separation of concerns, e.g. compilation vs. runtime), so just voicing an outsider’s preference for this to land before the branch (if it’s realistic that any open points can be solved during the rc-phase).
I haven’t put any thought into whether this is aiming for LLVM 17. I agree that this change will have effects on your packaging. In its current state flang-rt is working and addresses the high level goals discussed in this thread, but the patch hasn’t been heavily reviewed yet and I don’t know how long that may take. This patch touches a lot of infrastructure, it could have a large range of effect so we can’t be too hasty with the review process. That being said I’ll keep this in mind and see what I can do. What is the latest date this can be landed in order for it to still make LLVM 17?
I would kindly ask for 18 given the impact.
2 Likes
Apologies for not having much updates on the flang-rt runtime library creation/decoupling for the last couple weeks. The patch is now ready to be revisited. Testing support is now integrated into the project (via a new check-flang-rt target) and relevant testcases have been moved. There have been several other changes that overall make the patch more polished. Given the scope of the patch I would appreciate as many reviewers as I can so that we can avoid running into issues later. If anyone has any recommendations for community members I should add as reviewers besides those already added please let me know.
The patch landed and then got reverted; since then there’s been no activity on the PR – is this still planned / being pursued?
Update in the call yesterday was:
Patch is being reworked and will be submitted as a new PR when ready
See Page 6 of https://docs.google.com/document/d/1Z2U5UAtJ-Dag5wlMaLaW1KRmNgENNAYynJqLW2j2AZQ/edit
1 Like
This patch wasn’t mentioned in the minutes of the last two technical calls (last appearance was 2023-10-16) – any update on this? Is it still planned in the LLVM 18 timeframe, or at all?
@kiranchandramohan Base on the comments in the PR, this feature requires a different design. We are not currently working on the new design. We hope to come back to this feature in the future.
That’s unfortunate. I think the PR was a good change, and based on the comments there (especially post-merge), it seems to only have been reverted due to a missing -DLLVM_INSTALL_GTEST=ON flag and one overlooked -lFortranRuntime.
Which comments are you referring to that require a different design, @kkwli?
Context: changing the runtime setup like that will cause churn in build systems like CMake and meson as well as distribution (at least in conda-forge), so the earlier this is done, the better.
Sorry for the slow response. I think there were some discussions in flang technical call after the patch causing build breakages and then reverted. During discussions, it was suggested that a different approach is needed. Perhaps we can discuss it in the technical meeting again to sort out what is needed. Unfortunately, I won’t be available next Monday (Nov 27).
Jus to add a bit more details as we discussed in today’s Flang tech meeting call.
From the offline comments after the patch was reverted:
“Our basic problem is that the in-tree clang compiler will not run on our build machine.
When flang-rt is built, the llvm build system uses clang.
The CMakefiles are structured such that we cannot separate the build of flang and flang-rt.
We have the same issue with compiler-rt. For compiler-rt, we create a separate build.
The flang-rt commit, as it is structured, will add flang-rt to all flang builds. That prevents us from splitting out the flang-rt build.”
We wanted to investigate the approach of separating the flang-rt build, but haven’t got to it.
Anyone is welcome to either continue on this patch to fix the failures and get some more feedback via a PR, or investigate the possibility of separating the flang-rt as suggested here.
1 Like