[PGO] PGOFuncName meta data if PGOFuncName is different from function's raw name.

[xur]

Summary

Write out the PGOFuncName meta data if PGOFuncName is different from function's raw name. This should only apply to internal linkage functions. This is to be consumed by indirect-call promotion when called in LTO optimization passes (D17864 under review).

This patch depends on http://reviews.llvm.org/D18623.

[xur]

sync the change in D18623.

[davidxl]

lib/CodeGen/CodeGenPGO.cpp

791 ↗

(On Diff #52134)

This may not be the best place do set the data. Better to call it in setFuncName

[anemet]

As discussed under D17864, I did a run with this and I don't get the indirect call promoted that calls static functions in povray. I will dig more but do I need to pass some extra flag?

[xur]

I did not test Clang based instrumentation with SPEC. I will try it with
povray today.

[davidxl]

Can you also try IR based instrumentation? -fprofile-instr-generate
-Xclang=-fprofile-instrument=llvm

David

[anemet]

Thanks, the indirect call is via the All_Intersections macro in All_CSG_Intersect_Intersections and the top targets are: All_Sphere_Intersections and All_Plane_Intersections.

[xur]

Previous patch was bad (as David noticed) -- we might not annotate all the functions that we interested.

This updated patch should work.

BTW, I got the following promotions for 453.provay:

LLVM gold plugin: csg.cpp:157:15: Promote indirect call to _ZN3povL23All_Plane_IntersectionsEPNS_13Object_StructEPNS_10Ray_StructEPNS_13istack_structE with count 1654869 out of 1695169
LLVM gold plugin: csg.cpp:157:15: Promote indirect call to _ZN3povL31All_CSG_Intersect_IntersectionsEPNS_13Object_StructEPNS_10Ray_StructEPNS_13istack_structE with count 40300 out of 40300
LLVM gold plugin: csg.cpp:252:11: Promote indirect call to _ZN3povL24All_Sphere_IntersectionsEPNS_13Object_StructEPNS_10Ray_StructEPNS_13istack_structE with count 72389427 out of 132687016
LLVM gold plugin: csg.cpp:252:11: Promote indirect call to _ZN3povL23All_Plane_IntersectionsEPNS_13Object_StructEPNS_10Ray_StructEPNS_13istack_structE with count 44987633 out of 60297589
LLVM gold plugin: lighting.cpp:828:11: Promote indirect call to _ZN3povL31All_CSG_Intersect_IntersectionsEPNS_13Object_StructEPNS_10Ray_StructEPNS_13istack_structE with count 271222 out of 581624
LLVM gold plugin: lighting.cpp:828:11: Promote indirect call to _ZN3povL27All_Ellipsoid_IntersectionsEPNS_13Object_StructEPNS_10Ray_StructEPNS_13istack_structE with count 220561 out of 310402
LLVM gold plugin: objects.cpp:111:7: Promote indirect call to _ZN3povL31All_CSG_Intersect_IntersectionsEPNS_13Object_StructEPNS_10Ray_StructEPNS_13istack_structE with count 14382553 out of 16537858
LLVM gold plugin: objects.cpp:111:7: Promote indirect call to _ZN3povL23All_Plane_IntersectionsEPNS_13Object_StructEPNS_10Ray_StructEPNS_13istack_structE with count 1489615 out of 2155305
LLVM gold plugin: objects.cpp:175:11: Promote indirect call to _ZN3povL12Inside_PlaneEPdPNS_13Object_StructE with count 50136636 out of 70129039
LLVM gold plugin: objects.cpp:175:11: Promote indirect call to _ZN3povL14Inside_QuadricEPdPNS_13Object_StructE with count 16280600 out of 19992403
LLVM gold plugin: render.cpp:3579:9: Promote indirect call to _ZN3povL23Inside_CSG_IntersectionEPdPNS_13Object_StructE with count 4065174 out of 4516860
LLVM gold plugin: render.cpp:3579:9: Promote indirect call to _ZN3povL12Inside_PlaneEPdPNS_13Object_StructE with count 451686 out of 451686
LLVM gold plugin: spec_qsort.cpp:38:14: Promote indirect call to _ZN3povL9compboxesEPvS0_ with count 9339 out of 9339
LLVM gold plugin: textstreambuffer.cpp:278:4: Promote indirect call to _ZN12pov_frontend21DefaultRenderFrontend19DefaultStreamBuffer12directoutputEPKcj with count 9922 out of 9924
LLVM gold plugin: textstreambuffer.cpp:237:4: Promote indirect call to _ZN12pov_frontend21DefaultRenderFrontend19DefaultStreamBuffer10lineoutputEPKcj with count 9922 out of 9924

Adam: Could you try again?

Thanks,

-Rong

[anemet]

Sure, I'll try.

Also sounds like you are missing a test in this patch that fails with the old version but passes with the new?!

[davidxl]

lib/CodeGen/CodeGenPGO.cpp

47 ↗

(On Diff #54275)

This check be folded into the creator. The creator interface name also needs to be changed properly (created when needed)

[xur]

the reason for splitting the check is we don't need this check at all in
llvm instrument,-- as it's done per function. but I guess it does not
matter much to move it in to create -- it's only called once per function.

[anemet]

Still does not to work. The metadata has the full path for the file while the prof data only has the filename.

FTR, I applied this and the ICP patch on top of r266465.

[xur]

these two patches work fine in my build. My llvm was on top ov r265491. The
opt remarks in the last email were emitted by the compiler.

I'll try to reproduce with r266465.

[anemet]

Rong, do you have full paths or just the filename?

[xur]

I tried D17864 and D18624 with the latest trunk of r267006 on a clean
client.
The built compiler works fine with povray.

the meta data only has the files name.

How did you build povray?
can you show me your command line in building (for example, csg.cpp) for
both--fprofile-instr-use and -fprofile-instr-generate?

[anemet]

How did you build povray?
can you show me your command line in building (for example, csg.cpp) for
both--fprofile-instr-use and -fprofile-instr-generate?

Sent it in an email.

[xur]

I was using spec-run where the command line has the pathless filename.

The source in Atam's command-line has the absolute path.
In meta-data creation, we used Module's getSourceFileName() which has the
source name appeared in the command line (in this case, a full patch name).

While in Clang's setFuncName, it uses CGM.getCodeGenOpts().MainFileName.
This string strips the path from the source.

I can expand function createPGOFuncNameMetadata() to handle this (I mean
using the stripped name).

But I need to point out that stripping the patch may not a good idea as it
greatly increases the change name conflicts:
If we have
static bar() in dir1/foo.c
and
static bar() in dir2/foo.c

if the user compiler with:

clang ... dir1/foo.c
clang ... dir2/foo.c

With Clang's scheme, both functions would have PGOFuncName of foo.c:bar().
In IR instrumentation, we will have different name in this case:
dir1/foo.c:bar(), and dir2/foo.c:bar()

Of course, if the user compiles the code the following way:

cd dir1; clang foo.c
cd ../dir2; clang foo.c

we will have conflict for both instrumentation.
In this case, we can suggestion the user to have the relative path in the
build line.

[xur]

Handling the path-stripped prefix in PGOFuncName.

This new patch depends on http://reviews.llvm.org/D19433

[davidxl]

lgtm

[xur]

tested with povray with full path names in the command line and it works fine.

cfe/trunk/lib/CodeGen/CodeGenPGO.cpp

void CodeGenPGO::setFuncName(StringRef Name,
 
   // If we're generating a profile, create a variable for the name.
   if (CGM.getCodeGenOpts().hasProfileClangInstr())
     FuncNameVar = llvm::createPGOFuncNameVar(CGM.getModule(), Linkage, FuncName);
 }
 
 void CodeGenPGO::setFuncName(llvm::Function *Fn) {
   setFuncName(Fn->getName(), Fn->getLinkage());
+  // Create PGOFuncName meta data.
+  llvm::createPGOFuncNameMetadata(*Fn, FuncName);
 }
 
 namespace {
 /// \brief Stable hasher for PGO region counters.
 ///
 /// PGOHash produces a stable hash of a given function's control flow.
 ///
 /// Changing the output of this hash will invalidate all previously generated