This is an archive of the discontinued LLVM Phabricator instance.

Fix modules build for LLVMOrcShared
AbandonedPublic

Authored by sgraenitz on Jan 30 2021, 12:24 PM.

Details

Reviewers
teemperor
lhames
Summary

Follow-up from D92873. OrcShared shouldn't depend on intrinsics_gen, it should only include code that is required in both, OrcJIT and OrcTargetProcess. The former already depends on intrinsics_gen and the latter doesn't need it.

This is a minimal change for fixing the modules build while avoiding the OrcShared dependency to intrinsics_gen -- not necessarily final. I think there are two discussion topics here:
(1) Should we clean up the module map? It seems there are some outdated entries.
(2) Can we copy/move a subset of ExecutionEngine's JITSymbol.h to OrcShared as proposed here and/or improve it?

Diff Detail

Event Timeline

sgraenitz created this revision.Jan 30 2021, 12:24 PM
sgraenitz requested review of this revision.Jan 30 2021, 12:24 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 30 2021, 12:24 PM

@lhames Does anything prevent us from having a dedicated JITTargetAddress in OrcShared? Am I remembering correctly, that JITSymbol is last dependency to ExecutionEngine? Maybe, now that release 12 branched we could think about planning a change like this?

llvm/include/llvm/module.modulemap
196

These moved to OrcShared, but I don't get errors as is. So, can we just remove them?

212

Is OrcSupport meant as the lib we call OrcShared today?

Thanks for working on this! I think @lhames is the right person for any code restructuring, but I can review all the modulemap stuff.

llvm/include/llvm/module.modulemap
196

I don't think Clang reports missing excluded headers. I think the paths here should be update as I *believe* Clang otherwise compiles the headers twice into each module.

212

I think all the modules we have here are *supposed* to represent a specific library, but in some situations (like here) it's just a group of headers that at least allow us to compile everything as a module. If putting all the Orc/Shared headers into their own module works with the module build, then we can also rename this to LLVM_OrcShared and use an umbrella like in LLVM_DebugInfo_CodeView above.

I think it would be even better if we could split up the different headers into modules that match the specific libraries, e.g. LLVM_OrcJIT, LLVM_OrcTargetProcess, LLVM_OrcShared and a LLVM_ExecutionEngine module (the last one only contains the headers directly in ExecutionEngine, but given the comments above I'm not sure if we can modularize them).

lhames accepted this revision.Aug 27 2021, 3:20 AM

Sorry for the very delayed review!

@lhames Does anything prevent us from having a dedicated JITTargetAddress in OrcShared?

No. I recently added an ExecutorAddress class to OrcShared that I would like to use to slowly replace JITTargetAddress (in both ORC and JITLink), but I think that it is a good idea to have a dedicated JITTargetAddress in OrcShared to simplify the library story in the short term.

Am I remembering correctly, that JITSymbol is last dependency to ExecutionEngine? Maybe, now that release 12 branched we could think about planning a change like this?

I agree. I think we should wait until the current ExecutorProcessControl work settles down: that will allow us to remove a lot of existing code, which will make decoupling ORC from ExecutionEngine even easier. I think LLVM 14 or LLVM 15 is a reasonable timeframe for this.

This revision is now accepted and ready to land.Aug 27 2021, 3:20 AM

Hi Lang, thanks for your notes. I will leave this here as a reminder for myself and revisit the plan once it's time for the next release to branch.

sgraenitz abandoned this revision.Mar 23 2023, 3:51 AM

I never got around to it again and it doesn't look like that's going to change anytime soon. We still use JITSymbol.h in both, Orc and JITLink and we still have the dependency to intrinsics_gen.

Herald added a project: Restricted Project. · View Herald TranscriptMar 23 2023, 3:51 AM