This is an archive of the discontinued LLVM Phabricator instance.

[LegacyPM] Rename and deprecate populateModulePassManager
Needs ReviewPublic

Authored by MaskRay on Apr 19 2022, 9:47 PM.

Details

Summary

Using LLVM's legacy PM for optimization pipeline was deprecated in
13.0.0
and some rarely used pieces are being removed.

populateModulePassManager is a main API indicating legacy usage. Rename
and deprecate it to make users aware. Use a function attribute instead
of LLVM_ATTRIBUTE_DEPRECATED to allow warning suppression with #pragma
without worrying about MSVC.

Diff Detail

Event Timeline

MaskRay created this revision.Apr 19 2022, 9:47 PM
Herald added a reviewer: bollu. · View Herald Transcript
Herald added a reviewer: ctetreau. · View Herald Transcript
Herald added a reviewer: ctetreau. · View Herald Transcript
Herald added a reviewer: ctetreau. · View Herald Transcript
Herald added a reviewer: ctetreau. · View Herald Transcript
Herald added a project: Restricted Project. · View Herald Transcript
MaskRay requested review of this revision.Apr 19 2022, 9:47 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptApr 19 2022, 9:47 PM

Please do not change names in the FFI API at least. It's okay to drop it entirely, but renaming is unnecessarily hostile for FFI APIs.

clang/tools/clang-fuzzer/handle-llvm/handle_llvm.cpp
95

This seems like an easy usage to replace?

llvm/include/llvm-c/Transforms/PassManagerBuilder.h
72

Let's not promise any specific timeline. IMHO we should drop this as soon as there are no in-tree users anymore.

llvm/unittests/ExecutionEngine/MCJIT/MCJITCAPITest.cpp
317

This also looks like an easy usage to remove.

MaskRay marked an inline comment as done.Apr 20 2022, 12:36 AM

Please do not change names in the FFI API at least. It's okay to drop it entirely, but renaming is unnecessarily hostile for FFI APIs.

Why?

Please do not change names in the FFI API at least. It's okay to drop it entirely, but renaming is unnecessarily hostile for FFI APIs.

Why?

Users of the FFI interface generally target multiple LLVM versions, so they need to introduce checks to use one or the other API -- if lucky only compile-time checks, if not lucky it requires switching the code to use dlsym. This may be unavoidable if an API is removed, but it's an unnecessary complication for a rename.

MaskRay updated this revision to Diff 424374.Apr 21 2022, 9:35 PM

I still do not see the argument about C API, but I just drop that changes.

I'd first fix up as many in-tree users as nikic pointed out

(I'll work on bugpoint soonish since that requires a bit more work)

llvm/include/llvm-c/Transforms/PassManagerBuilder.h
72

can we use llvm/include/llvm-c/Deprecated.h for the C API here? looks like we only have on in-tree user in llvm/unittests/ExecutionEngine/MCJIT/MCJITCAPITest.cpp that we should be able to clean up

Apologies if this isn't directly related to this patch in particular, but is there a more informative message that could be given than "Migrate to new pass manager"? In particular, for non-C language bindings that currently call LLVMPassManagerBuilderPopulateModulePassManager, any pointers to what functions in the C API should be used instead would be very helpful.

ormris removed a subscriber: ormris.May 16 2022, 11:27 AM

So nobody has managed to fix all the in-tree usage. I think having this for the upcoming release/15.x will be nice...

polly and clang-fuzzer both call populateModulePassManager just to optimize IR, they should be easily migrated to use the new PM

bugpoint is still an issue, I just haven't found time to work on it yet