This is an archive of the discontinued LLVM Phabricator instance.

[SampleFDO][NFC] Refactor SampleProfile.cpp
ClosedPublic

Authored by xur on Feb 10 2021, 2:36 PM.

Details

Summary

This is a follow-up refactor patch to https://reviews.llvm.org/D95832
[SampleFDO][NFC] Refactor SampleProfileLoad to reuse the code in CodeGen

The main changes are:
(1) Move SampleProfileLoaderBaseImpl class to a header file: include/llvm/ProfileData/SampleProfileLoaderBaseImpl.h.
(2) Split SampleCoverageTracker to a head file: include/llvm/ProfileData/SampleProfileLoaderBaseUtil.h,
and a cpp file: lib/ProfileData/SampleProfileLoaderBaseUtil.cpp.
(3) Make the pointer reference to SampleCoverageTracker in the base class. This is to break the dependence from SampleProfileLoaderBaseImpl to SampleCoverageTracker. All the references will be through the wrapper functions.
(4) Move the common codes (common options and callsiteIsHot()) to lib/ProfileData/SampleProfileLoaderBaseUtil.cpp.

Diff Detail

Event Timeline

xur created this revision.Feb 10 2021, 2:36 PM
xur requested review of this revision.Feb 10 2021, 2:36 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 10 2021, 2:36 PM
xur edited the summary of this revision. (Show Details)Feb 10 2021, 2:38 PM
xur edited the summary of this revision. (Show Details)
wmi added inline comments.Feb 10 2021, 11:17 PM
llvm/include/llvm/ProfileData/SampleProfileLoaderBaseUtil.h
28–29

avoid using namespace in header file.

xur retitled this revision from SampleFDO][NFC] Refactor SampleProfile.cpp to [SampleFDO][NFC] Refactor SampleProfile.cpp.Feb 11 2021, 11:23 AM
xur updated this revision to Diff 323097.Feb 11 2021, 11:26 AM

Integrated Wei's review comment.

I need to include "using llvm" etc in the header file, as the code below is going to refer the symbols in the namespace.
To avoid affecting other headers, I put the code into a llvm namespace scope.

xur added a reviewer: hoy.Feb 11 2021, 1:01 PM
wmi added a comment.Feb 11 2021, 1:28 PM

It looks cleaner to remove the wrappers at the cost of including SampleProfileLoaderBaseUtil.h in SampleProfileLoaderBaseImpl.h.

xur updated this revision to Diff 323131.Feb 11 2021, 1:33 PM
xur marked an inline comment as done.

Here is the version include the definition of SampleCoverageTracker in the base class.
Without using the wrapper functions, it does look a bit cleaner.

wmi accepted this revision.Feb 11 2021, 3:42 PM

LGTM. Better wait and see if Hongtao and Wenlei have other comments. This refactoring patch will substantially affect their integration.

This revision is now accepted and ready to land.Feb 11 2021, 3:42 PM

WeiLei and Hongtao, do you have any concerns / comments? If not, I will
commit this change today.

Thanks,

-Rong

hoy accepted this revision.Feb 16 2021, 10:51 AM

Sorry for the late response. We've been thinking about the integration with CSSPGO. May need to move more stuff (like getProbeWeight) into the base class for MIR support.

Current changes look good to me. Thanks.

xur added a comment.Feb 16 2021, 11:00 AM

Thanks for the update!
I agree that the probe based part can be moved to the base later. Once all
the lineno based code is in place, moving code should be straightforward.

-Rong

This revision was automatically updated to reflect the committed changes.

Had to revert in c761fe77bdca ; it seems like this broke the build with -DBUILD_SHARED_LIBS=ON (logs: https://buildkite.com/mlir/mlir-core/builds/11629#4fb463ba-9c88-4439-95a5-147c6960ff4b )

vsk added a subscriber: vsk.Feb 16 2021, 2:22 PM

Hi @xur, just a heads-up that this also appears to have introduced a cyclic dependency issue which broke the LLVM_ENABLE_MODULES=On build:

While building module 'LLVM_Transforms' imported from /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/ExecutionEngine/Orc/IndirectionUtils.h:24:
While building module 'LLVM_Analysis' imported from /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/Transforms/Coroutines/CoroSplit.h:18:
While building module 'LLVM_ProfileData' imported from /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/Analysis/IndirectCallPromotionAnalysis.h:16:
In file included from <module-includes>:12:
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/ProfileData/SampleProfileLoaderBaseImpl.h:24:10: fatal error: cyclic dependency in module 'LLVM_Analysis': LLVM_Analysis -> LLVM_ProfileData -> LLVM_Analysis
#include "llvm/Analysis/LoopInfo.h"

http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/28897/consoleText

xur added a comment.Feb 16 2021, 3:08 PM

Yes. I'm aware of this. I had a fix already. Testing it now.

-Rong

vsk added a comment.Feb 17 2021, 10:26 AM

Thanks for taking a look @xur. Unfortunately I needed to revert this again, as llc is still failing to build (see c28622fbf363d8ade9598ea6ffb88cb9a8f7604f):

duplicate symbol 'llvm::SampleProfileLoaderBaseImpl::findEquivalenceClasses(llvm::Function&)' in:
    tools/llc/CMakeFiles/llc.dir/llc.cpp.o
    lib/libLLVMInstCombine.a(InstCombineVectorOps.cpp.o)

I believe the problem is that you have definitions like SampleProfileLoaderBaseImpl::findEquivalenceClasses that get imported into multiple TU's, then conflict at link-time. These probably need to be sunk into some .cpp and built just once (would also be better for compile time).

xur added a comment.Feb 17 2021, 10:40 AM

Thanks for reporting this.
What config this failure is using? I don't see this error in my builds.
This is an intermediate step for templatelizing the code. I don't think
this will be a problem for the templated headers.

-Rong

vsk added a comment.Feb 17 2021, 11:57 AM

This particular bot is using -DLLVM_ENABLE_MODULES=On. I'm not sure how to explain why the issue doesn't pop up on other bots. My current theory is that the LLVM_ProfileData module re-exports the new header because of:

module LLVM_ProfileData {
  requires cplusplus

  umbrella "ProfileData"
  module * { export * } //< This?

  textual header "ProfileData/InstrProfData.inc"
}

If SampleProfileLoaderBaseImpl is indeed imported from Transforms/Utils, then the re-export from the ProfileData module might cause the duplicate definition link failure, even though there's only one #include for the header.

I'd wager that the simplest fix would be to pull the header definitions from SampleProfileLoaderBaseImpl into a .cpp. If/when those definitions become templated they can move back into the header. Alternatively perhaps the modulemap file can be changed to not re-export SampleProfileLoaderBaseImpl, but I don't know how to make that change or how invasive it'd be.

xur added a comment.Feb 17 2021, 1:42 PM

Adding "inline" keywords will make the functions COMDAT and will fix the
duplicates problem. I verified with -DLLVM_ENABLE_MODULES=On.

Once we make the class a template, we don't need the "inline" keywords. I
also verified this with my template patch.

I will do a few more tests and will commit a modified patch with "inline"
keywords.