Hello all,
As of now, all LLVM and Clang tests have been updated/addressed to run under the new/experimental pass manager (at least the ones that failed when using the new PM).
For those who aren’t aware of what the new pass manager (PM) is, the tl;dr is that this will serve as a replacement for the legacy PM, and promises faster build times by restructuring how passes are run over IR units. For some time, when someone wants to create a new pass, they may need to implement it for both pass managers since the legacy one is what is enabled by default. Passes that were initially made under the new PM have also slowly been ported over time.
Now that LLVM 9.0.0 has branched, we have about 6 months before the next release. We think it would be a good idea to take this opportunity and make the new PM the default one which gives us enough time to work out any kinks that might come out of this switch before LLVM 10.0.0 branch point. We suspect that there may be other LLVM projects that will be affected by this, probably from unported passes.
Does anyone have any opinions on this?
Off the top of my head, the next immediate work would be to update the docs with instructions on how to write or port a new PM pass, and address any breakages for other LLVM projects.
Thanks,
Leonard
I just wanted to say: huge +1 from me, and a huge thanks to you and several others who have been working tirelessly to track down the long tail of issues and get them resolved so we could get to this point.
Hello all,
As of now, all LLVM and Clang tests have been updated/addressed to run under the new/experimental pass manager (at least the ones that failed when using the new PM).
For those who aren't aware of what the new pass manager (PM) is, the tl;dr is that this will serve as a replacement for the legacy PM, and promises faster build times by restructuring how passes are run over IR units. For some time, when someone wants to create a new pass, they may need to implement it for both pass managers since the legacy one is what is enabled by default. Passes that were initially made under the new PM have also slowly been ported over time.
Now that LLVM 9.0.0 has branched, we have about 6 months before the next release. We think it would be a good idea to take this opportunity and make the new PM the default one which gives us enough time to work out any kinks that might come out of this switch before LLVM 10.0.0 branch point. We suspect that there may be other LLVM projects that will be affected by this, probably from unported passes.
Does anyone have any opinions on this?
A huge thank you to everyone who has worked on this! This is great news. You're exactly right: we should change the default early in the release cycle. +1 to doing this.
-Hal
Off the top of my head, the next immediate work would be to update the docs with instructions on how to write or port a new PM pass, and address any breakages for other LLVM projects.
Thanks,
Leonard
Hooray!! You have no idea how happy this makes me. Thank you for the great work!
-Chris
Thanks for all the hard work that went into getting it here.
+1
Can you spell out what performance validation has been done? Informally, I know there’s been quite a bit, but getting a summary in one place for later reference would be super helpful.
Philip
I think so far most individual projects have their own statistics on build time/performance impact on switching to the new PM, but I agree that there should at least be one place that people can reference on the impact.
Hi Leonard,
Is the new pass manager expected to work with sanitizers now?
I believe a good amount of them (if not most of them) have already been ported! Off the top of my head, I remember that asan, tsan, msan, hwasan, the kernel santizers, and sancov have been ported. I don’t think ubsan has been ported yet though.
You can also check if other passes you need run under the new PM by checking PassRegistry.def.
OK. I have a tsan crash to report, will file shortly 
FWIW, we’ve been using the new pass manager for a long time now in our non-sanitizer builds, and haven’t noticed issues other than a few compiler crashes, which mostly seem due to people testing only with the legacy pass manager.
Getting ubsan ported would be good if it hasn't. Do you happen to know
what's needed there?
-eric
Getting ubsan ported would be good if it hasn't. Do you happen to know
what's needed there?
Are we sure that there's anything to port? I thought that ubsan's
instrumentation is added in Clang's codegen, not by an instrumentation
pass. I don't see anything in BackendUtil.cpp that jumps out at me as
ubsan (I might be missing something because ubsan is really a sanitizer
group in Clang, not an individual sanitizer, so it's broken up into a
large number of flags).
-Hal
> Getting ubsan ported would be good if it hasn't. Do you happen to know
> what's needed there?
Are we sure that there's anything to port? I thought that ubsan's
instrumentation is added in Clang's codegen, not by an instrumentation
pass. I don't see anything in BackendUtil.cpp that jumps out at me as
ubsan (I might be missing something because ubsan is really a sanitizer
group in Clang, not an individual sanitizer, so it's broken up into a
large number of flags).
That was my thought too, but I was willing to go with "Leonard may
have found something"
-eric
+1 from me, but I think we should keep some bots running on the old
pass manager, to make sure the failures aren't just because of the new
pass manager's structure.
At least for a while, until we have enough coverage on all buildbots
and feedback from enough downstream projects that all is well.
Hello all,
As of now, all LLVM and Clang tests have been updated/addressed to run under the new/experimental pass manager (at least the ones that failed when using the new PM).
For those who aren't aware of what the new pass manager (PM) is, the tl;dr is that this will serve as a replacement for the legacy PM, and promises faster build times by restructuring how passes are run over IR units. For some time, when someone wants to create a new pass, they may need to implement it for both pass managers since the legacy one is what is enabled by default. Passes that were initially made under the new PM have also slowly been ported over time.
Now that LLVM 9.0.0 has branched, we have about 6 months before the next release. We think it would be a good idea to take this opportunity and make the new PM the default one which gives us enough time to work out any kinks that might come out of this switch before LLVM 10.0.0 branch point. We suspect that there may be other LLVM projects that will be affected by this, probably from unported passes.
Does anyone have any opinions on this?
What is involved in making the new pass manager the default?
Does it just mean updating clang, or will the C API functions,
like LLVMCreatePassManager(), etc. be updated too?
-Tom
One option is just to change the default for ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER in Clang’s CMakeLists.txt: https://github.com/llvm/llvm-project/blob/0930643ff6f1684bf234a97f6a3b76bf8e30b0a1/clang/CMakeLists.txt#L236. That approach allows developers and bots to easily switch back to the legacy pass manager by simply passing -DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=OFF to their CMake build.