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

[Rong Xu via cfe-commits]

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.



On Thu, Apr 21, 2016 at 11:23 AM, Adam Nemet <anemet at apple.com> wrote:

> anemet added a comment.
>
> > 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.
>
>
> http://reviews.llvm.org/D18624
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160421/6cb5c452/attachment.html>