This is an archive of the discontinued LLVM Phabricator instance.

[PGO] Turn off comdat renaming in IR PGO by default
ClosedPublic

Authored by xur on Jan 6 2017, 2:55 PM.

Details

Summary

In IR PGO we append the function hash to comdat functions to avoid the
potential hash mismatch. This turns out not legal in some cases: if the comdat
function is address-taken and used in comparison. Renaming changes the semantic.

This patch turns off comdat renaming by default.

To alleviate the hash mismatch issue, we now rename the profile variable
for comdat functions. Profile allows co-existing multiple versions of profiles
with different hash value. The inlined copy will always has the correct profile
counter. The out-of-line copy might not have the correct count. But we will
not have the bogus mismatch warning.

Event Timeline

xur updated this revision to Diff 83438.Jan 6 2017, 2:55 PM
xur retitled this revision from to [PGO] Turn off comdat renaming in IR PGO by default.
xur updated this object.
xur added a reviewer: davidxl.
xur added subscribers: xur, llvm-commits.
davidxl edited edge metadata.Jan 6 2017, 4:21 PM

needs a profile use test case such that a comdat function has multiple copies of profile data and the profile annotator can find the one with the matching hash.

include/llvm/ProfileData/InstrProf.h
237

Add comments: instances of the same comdat function may have different control flows thus can not share the same counter variable.

238

canRenameComdatFunc

lib/Transforms/Instrumentation/InstrProfiling.cpp
35

-> DoHashBasedCounterSplit

37

"Rename counter variable of a comdat function based on cfg hash".

xur updated this revision to Diff 83652.Jan 9 2017, 10:40 AM
xur edited edge metadata.

D28416: [PGO] Turn off comdat renaming in IR PGO by default

Integrated David's review comments:
(1) added a multiple comdat copies test case.
(2) changed naming and comments.

davidxl added inline comments.Jan 10 2017, 9:58 AM
lib/ProfileData/InstrProf.cpp
839

Given the name of the function, it should probably check address taken bit as well.

lib/Transforms/Instrumentation/InstrProfiling.cpp
285

appent --> append

285

why there is on hash? or it is hash of a trivial function?

lib/Transforms/Instrumentation/PGOInstrumentation.cpp
410

It is clearer to check DoComdatRenaming here as well.

xur marked an inline comment as done.Jan 10 2017, 10:19 AM
xur added inline comments.
lib/ProfileData/InstrProf.cpp
839

We can do that, but it won't completely solve the issue as the address taken can happen in other TU.

lib/Transforms/Instrumentation/InstrProfiling.cpp
285

this can be called directly from intrinsic in a .ll file (happen some test cases), but since we now check the IRPGO bit, we can remove this.

lib/Transforms/Instrumentation/PGOInstrumentation.cpp
410

I can add the check, but this essentially gonna be redundant: we only collect ComdatMembers under DoComdatRenaming. And we only call canRenameComdat when ComdatMembers is not empty.
So when DoComdatRenming is false, we will not call canRenameComdat.

davidxl added inline comments.Jan 10 2017, 10:25 AM
lib/ProfileData/InstrProf.cpp
839

Yes -- that is why it is better to add the check here and document 1) why it is not safe to be on by default 2) even when it is on, there is a risk as you mentioned.

lib/Transforms/Instrumentation/PGOInstrumentation.cpp
410

Right -- it is clearer this way.

xur updated this revision to Diff 83833.Jan 10 2017, 11:29 AM

updated patch
Integrated David's review comments.
Note I need to conditionally check addresstaken bit in
canRenameComdatFunc() as this function is also used in renaming profile
variable which does not care if address-taken or not.
Also checking this bit requries the update of one test case.

davidxl accepted this revision.Jan 10 2017, 11:35 AM
davidxl edited edge metadata.

lgtm

This revision is now accepted and ready to land.Jan 10 2017, 11:35 AM
xur closed this revision.Jan 10 2017, 11:41 AM