Summary:
This patch is a refactoring of the way cmake 'targets' are grouped.
It won't affect non-UI cmake-generators.
Clang/LLVM are using a structured way to group targets which ease
navigation through Visual Studio UI. The Compiler-RT projects
differ from the way Clang/LLVM are grouping targets.
This patch doesn't contain behavior changes.
Reviewers: kubabrecka, rnk
Subscribers: wang0109, llvm-commits, kubabrecka, chrisha
Differential Revision: http://reviews.llvm.org/D21952
llvm-svn: 275111
Here's the warnings and how they were fixed:
- InstrProfilingUtil.c(110): warning C4013: '_open_osfhandle' undefined; assuming extern returning int
Include io.h to get the prototype.
- warning C4005: 'FILE_MAP_EXECUTE': macro redefinition
Stop trying to support pre-XP versions of Windows, don't attempt to
define this macro.
- InstrProfilingWriter.c(271): warning C4221: nonstandard extension used: 'Data': cannot be initialized using address of automatic variable 'Header'
- InstrProfilingWriter.c(275): warning C4221: nonstandard extension used: 'Data': cannot be initialized using address of automatic variable 'Zeroes'
Turn this warning off. This is definitely legal in C++, all compilers
accept it, and I only have room for half of one language standard in my
brain.
- InstrProfilingValue.c(320): warning C4113: 'uint32_t (__cdecl *)()' differs in parameter lists from 'uint32_t (__cdecl *)(void)'
Fix this with an explicit (void) in the prototype.
- InstrProfilingMerge.c.obj : warning LNK4006: _VPMergeHook already defined in InstrProfilingMergeFile.c.obj; second definition ignored
Last remaining warning. This is from linking a selectany definition with
a strong definition. We need to sort out weak symbols in compiler-rt in
general, though.
llvm-svn: 273026
- lprofCurFilename was intended to have external visibility. This is
pending further discussion.
- The raw version number doesn't need to be hidden: hiding it may make
it easier to accidentally combine FE/IR profiles.
See the mailing list discussion on r272081.
llvm-svn: 272089
There are still a few external symbols visible from InstrProfData.inc.
The plan for dealing with those isn't as straightforward, so I'll try it
in a separate commit.
llvm-svn: 272081
(Part-1 merging API is in profile runtime)
This patch implements a portable file opening API
with exclusive access for the process. In-process
profile merge requires profile file update to be
atomic/fully sychronized.
llvm-svn: 271864
The max warning check was masking the "return 0" codepath.
See the thread "Warnings and compile-time failure on 458.sjeng" for more
info.
llvm-svn: 270762
After r270617 I am getting an error when building:
projects/compiler-rt/lib/profile/InstrProfilingFile.c:33:36:
error: missing field 'PidChars' initializer
[-Werror,-Wmissing-field-initializers]
lprofFilename lprofCurFilename = {0};
^
Fix the aggregate initializer.
llvm-svn: 270697
licensees actually see in the toolchain we deliver to them. This will
reduce the set of local patches we have to maintain. The triple is
not changing. (The term ORBIS is an internal code name for PS4.)
llvm-svn: 269672
This is part-3 of the effort to eliminate dependency on
libc allocator in instr profiler runtime. With this change,
the profile dumper is completely free of malloc/calloc.
Value profile instr API implementation is the only remaining
piece with calloc dependency.
llvm-svn: 269576
This reverts commit r269493 as the corresponding LLVM commit was
reverted due to lots of warnings. See the review thread for the original
LLVM commit (r269491) for details.
llvm-svn: 269550
With this change, dynamic memory allocation is only used
for testing purpose. This change is one of the many steps to
make instrument profiler dynamic allocation free.
llvm-svn: 269453
This reverts commit r268840, as it breaks Thumb2 self-hosting. There is something
unstable in the profiling for Thumb2 that needs to be sorted out before we continue
implementing these changes to the profiler. See PR27667.
llvm-svn: 268864
to function names
Summary:
Hopefully this will make it easier for the next person to figure all
this out...
Reviewers: bogner, davidxl
Subscribers: davidxl, cfe-commits
Differential Revision: http://reviews.llvm.org/D18489
llvm-svn: 264680
This is implicitly needed at least by gcc-flag-compatibility.test
The thing that needs it is the `\` preceding the "default.profraw"
appended internally by clang when doing `-fprofile-use=`.
Clang uses `\` because is uses sys::path::append which will use `\` on a
Windows host. This is wrong, but I don't think there's an easy way to
solve it (maybe just always using `/` since places that accept `\` also
tend to accept `/`, but not the other way around).
llvm-svn: 264665
Summary:
Hopefully this will make it easier for the next person to figure all
this out...
Reviewers: bogner, davidxl
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D18490
llvm-svn: 264612
The GCDA writer closed the arc file before unlocking it. This causes an
EBADF while unlocking the file, and opens us up to racy behavior.
Fixes PR26847.
llvm-svn: 262779
Summary:
Hi David, SCE folks,
What is implemented in this patch is enough for the upstream libprofile to
work for PGO with the PS4 game codebase I tested ("game7" for you SCE
folks; this is with a standalone build of compiler-rt).
The first change, which is simple, is to stub out gethostname. PS4
doesn't have a simple analog for this that doesn't bring in extra
OS libraries, so for now we do not support `%h` expansion.
This is consistent with internal B#136272.
The second change implies future work, but is a simple change at present.
PS4 does not have `getenv`, so for now we will introduce a shim.
This obviously makes it impossible for many of the tests to be run since
they require setting `LLVM_PROFILE_FILE=`.
I see two paths forward:
1. In the tests we are already wrapping execution with `%run` and so by
setting a PS4-specific expansion for `%run` we can pass the information
in another way We can adapt the getenv shim as appropriate.
We will need to experiment with this internally.
Maggie, Phillip, Filipe? Any ideas? Maybe ping me internally since we
may need to get into some PS4 vagaries. I'm thinking a fake getenv
library that uses some side channel for communication.
2. Another possibility which is more verbose is to use a separate clang
invocation with `-profile-generate=<filename>` to set the filename in
each test.
This might require redundant clang invocations though which may be
undesirable for upstream. David, thoughts?
Also, this is a fairly libprofile-specific workaround, so it e.g.
doesn't help Filipe's ASan work.
Overall, this approach sounds like a bit of a hack to me.
Small detail:
InstrProfilingPort.h seems like the natural place for the getenv shim,
but GCDAProfiling.c needs it as well. InstrProfilingUtil.h is currently
the only header common between InstrProfilingFile.c and GCDAProfiling.c.
I can move the shim to InstrProfilingPort.h and add an include to
GCDAProfiling.c as per your preference David.
Reviewers: davidxl, MaggieYi, phillip.power, filcab
Subscribers: simon.f.whittaker, slingn, probinson, llvm-commits
Differential Revision: http://reviews.llvm.org/D17676
llvm-svn: 262527
Compiler-rt miscalculates the number of entries in the __llvm_prf_data section
on i386 Darwin. This results in a number of test failures (which we started
catching after r261344).
The fix we attempted earlier is insufficient (r261683). It caused some tests to
start passing again, but that hid the fact that we drop some data entries.
This patch should fix the real problem. It fixes the way we compute DataSize by
taking into account the way the Darwin linker lays out __llvm_prf_data.
Differential Revision: http://reviews.llvm.org/D17623
llvm-svn: 261957
Fix a crash when gathering value profile data on i386 Darwin.
The Darwin linker shrinks sections containing aligned structures when
padding is not explicitly added to the end of the structure. When
iterating over these structures, be sure to not walk past the end of the
section.
No tests added, since running `ninja check-profile` on i386 Darwin is
enough to reproduce the original crash.
llvm-svn: 261683
It thinks that these functions don't match the function pointer type
that they are passed with:
GCDAProfiling.c(578) : warning C4113: 'void (__cdecl *)()' differs in parameter lists from 'void (__cdecl *)(void)'
GCDAProfiling.c(579) : warning C4113: 'void (__cdecl *)()' differs in parameter lists from 'void (__cdecl *)(void)'
GCDAProfiling.c(580) : warning C4113: 'void (__cdecl *)()' differs in parameter lists from 'void (__cdecl *)(void)'
llvm-svn: 260475
Xinliang David Li