Inside `getCurFilename`, there is this code snippit
```
if (!lprofCurFilename.FilenamePat || !lprofCurFilename.FilenamePat[0])
return 0;
```
If this is true, we return `"\0"`, but would leak the memory in
`FilenameBuf`.
This pull request adds a free before then to properly free the memory.
There was already a check that we allocated memory, so there is no need
to worry about freeing unallocated memory.
This PR partially reverts 83e180c and instead opts to not define the GPU entry
point on Darwin platforms. Marking `__llvm_write_custom_profile` as used
was causing issues on embedded platforms.
On AIX, when accessing mmap'ed memory associated to a file on NFS, a
SIGBUS might be raised at random.
The problem is still in open state with the OS team.
This PR teaches the profile runtime, under certain conditions, to avoid
the mmap when reading the profile file during online merging.
This PR has no effect on any platform other than AIX because I'm not
aware of this problem on other platforms.
Other platforms can easily opt-in to this functionality in the future.
The logic in function `is_local_filesystem` was copied from
[llvm/lib/Support/Unix/Path.inc](f388ca3d9d/llvm/lib/Support/Unix/Path.inc (L515))
(https://reviews.llvm.org/D58801), because it seems that the
compiler-rt/profile cannot reuse code from llvm except through
`InstrProfData.inc`.
Thanks to @hubert-reinterpretcast for substantial feedback downstream.
---------
Co-authored-by: Wael Yehia <wyehia@ca.ibm.com>
Co-authored-by: Hubert Tong <hubert.reinterpretcast@gmail.com>
This pull request is the third part of an ongoing effort to extends PGO
instrumentation to GPU device code and depends on
https://github.com/llvm/llvm-project/pull/93365. This PR makes the
following changes:
- Allows PGO flags to be supplied to GPU targets
- Pulls version global from device
- Modifies `__llvm_write_custom_profile` and `lprofWriteDataImpl` to
allow the PGO version to be overridden
On AIX, when accessing mmap'ed memory associated to a file on NFS, a
SIGBUS might be raised at random.
The problem is still in open state with the OS team.
This PR teaches the profile runtime, under certain conditions, to avoid
the mmap when reading the profile file during online merging.
This PR has no effect on any platform other than AIX because I'm not
aware of this problem on other platforms.
Other platforms can easily opt-in to this functionality in the future.
The logic in function `is_local_filesystem` was copied from
[llvm/lib/Support/Unix/Path.inc](f388ca3d9d/llvm/lib/Support/Unix/Path.inc (L515))
(https://reviews.llvm.org/D58801), because it seems that the
compiler-rt/profile cannot reuse code from llvm except through
`InstrProfData.inc`.
Thanks to @hubert-reinterpretcast for substantial feedback downstream.
---------
Co-authored-by: Wael Yehia <wyehia@ca.ibm.com>
Co-authored-by: Hubert Tong <hubert.reinterpretcast@gmail.com>
This pull request fixes an issue that was introduced in #93365.
`__llvm_write_custom_profile` visibility was causing issues on Darwin.
This function needs to be publicly accessible in order to be accessed by
libomptarget, so this pull request makes `__llvm_write_custom_profile`
an explicitly exported symbol on Darwin. Tested on M3 and X86 macs.
This pull request is the second part of an ongoing effort to extends PGO
instrumentation to GPU device code and depends on #76587. This PR makes
the following changes:
- Introduces `__llvm_write_custom_profile` to PGO compiler-rt library.
This is an external function that can be used to write profiles with
custom data to target-specific files.
- Adds `__llvm_write_custom_profile` as weak symbol to libomptarget so
that it can write the collected data to a profraw file.
- Adds `PGODump` debug flag and only displays dump when the
aforementioned flag is set
Add support for expanding `%b` in `LLVM_PROFILE_FILE` to the binary ID
(build ID). It can be used with `%m` to avoid its signature collisions.
This is supported on all platforms where writing binary IDs into
profiles is implemented, as the `__llvm_write_binary_ids` function is
used.
Fixes#51560.
As detailed in Issue #101667, two `profile` tests `FAIL` on 32-bit
SPARC, both Linux/sparc64 and Solaris/sparcv9 (where the tests work when
enabled):
```
Profile-sparc :: ContinuousSyncMode/runtime-counter-relocation.c
Profile-sparc :: ContinuousSyncMode/set-file-object.c
```
The Solaris linker provides the crucial clue as to what's wrong:
```
ld: warning: symbol '__llvm_profile_counter_bias' has differing sizes:
(file runtime-counter-relocation-17ff25.o value=0x8; file libclang_rt.profile-sparc.a(InstrProfilingFile.c.o) value=0x4);
runtime-counter-relocation-17ff25.o definition taken
```
In fact, the types in `llvm` and `compiler-rt` differ:
- `__llvm_profile_counter_bias`/`INSTR_PROF_PROFILE_COUNTER_BIAS_VAR` is
created in `llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp`
(`InstrLowerer::getCounterAddress`) as `int64_t`, while
`compiler-rt/lib/profile/InstrProfilingFile.c` uses `intptr_t`. While
this doesn't matter in the 64-bit case, the type sizes differ for
32-bit.
- `__llvm_profile_bitmap_bias`/`INSTR_PROF_PROFILE_BITMAP_BIAS_VAR` has
the same issue: created in `InstrProfiling.cpp`
(`InstrLowerer::getBitmapAddress`) as `int64_t`, while
`InstrProfilingFile.c` again uses `intptr_t`.
This patch changes the `compiler-rt` types to match `llvm`. At the same
time, the affected testcases are enabled on Solaris, too, where they now
just `PASS`.
Tested on `sparc64-unknown-linux-gnu`, `sparcv9-sun-solaris2.11`,
`x86_64-pc-linux-gnu`, and `amd64-pc-solaris2.11.
Problem:
On AIX, functions registered by atexit in a shared library are not run
when the library is dlclosed, but instead run (and fail because the
function pointer is no longer valid) during main program exit.
The profile-rt registers some functions with atexit:
1. writeFileWithoutReturn that writes out the profile file
2. llvm_delete_reset_function_list that does some cleanup in the gcov
instrumentation library (not sure)
And so right now, we get an "Illegal instruction (core dumped)" when an
instrumented shared object is dlopen'ed and dlclosed.
Solution:
When a shared library is dlclose'd, destructors from the library are
called. So create a destructor function that iterates over all known
functions that profile-rt registers with atexit, and unregister the ones
that have been registered and execute them.
Scenarios tested:
(0) gcov dlopen/dlclose (AIX/gcov-dlopen-dlclose.test)
(1) multiple dlopen/dlclose of the same lib and multiple libs (instrprof-dlopen-dlclose.test)
(2) dlopen but no dlclose (exists: Posix/instrprof-dlopen.test)
(3) a simple fork testcase with dlopen/dlclose (instrprof-dlopen-dlclose.test)
(4) dlopen/dlclose by multiple threads. (instrprof-dlopen-dlclose.test)
(5) regular dynamic-linking of instrumented shared libs (exists: AIX/shared-bexpall-pgo.c)
(6) a simple fork testcase produces correct profile (instrprof-fork.c)
---------
Co-authored-by: Hubert Tong <hstong@ca.ibm.com>
`counter_bias` is incompatible to Bitmap. The distance between Counters
and Bitmap is different between on-memory sections and profraw image.
Reference to `__llvm_profile_bitmap_bias` is generated only if
`-fcoverge-mcdc` `-runtime-counter-relocation` are specified. The
current implementation rejected their options.
```
Runtime counter relocation is presently not supported for MC/DC bitmaps
```
This reverts commit 7cf84d3b0bc5eda3a907dfd026d51a17e28114a3.
(llvmorg-19-init-14939-g7cf84d3b0bc5)
This has my wrong assumptions possibly. This was failing fuchsia.
New change on top of [reviewed
patch](https://github.com/llvm/llvm-project/pull/81691) are [in commits
after this
one](d0757f46b3).
Previous commits are restored from the remote branch with timestamps.
1. Fix build breakage for non-ELF platforms, by defining the missing
functions {`__llvm_profile_begin_vtables`, `__llvm_profile_end_vtables`,
`__llvm_profile_begin_vtabnames `, `__llvm_profile_end_vtabnames`}
everywhere.
* Tested on mac laptop (for darwins) and Windows. Specifically,
functions in `InstrProfilingPlatformWindows.c` returns `NULL` to make it
more explicit that type prof isn't supported; see comments for the
reason.
* For the rest (AIX, other), mostly follow existing examples (like this
[one](f95b2f1acf))
2. Rename `__llvm_prf_vtabnames` -> `__llvm_prf_vns` for shorter section
name, and make returned pointers
[const](a825d2a4ec (diff-4de780ce726d76b7abc9d3353aef95013e7b21e7bda01be8940cc6574fb0b5ffR120-R121))
**Original Description**
* Raw profile format
- Header: records the byte size of compressed vtable names, and the
number of profiled vtable entries (call it `VTableProfData`). Header
also records padded bytes of each section.
- Payload: adds a section for compressed vtable names, and a section to
store `VTableProfData`. Both sections are padded so the size is a
multiple of 8.
* Indexed profile format
- Header: records the byte offset of compressed vtable names.
- Payload: adds a section to store compressed vtable names. This section
is used by `llvm-profdata` to show the list of vtables profiled for an
instrumented site.
[The originally reviewed
patch](https://github.com/llvm/llvm-project/pull/66825) will have
profile reader/write change and llvm-profdata change.
- To ensure this PR has all the necessary profile format change along
with profile version bump, created a copy of the originally reviewed
patch in https://github.com/llvm/llvm-project/pull/80761. The copy
doesn't have profile format change, but it has the set of tests which
covers type profile generation, profile read and profile merge. Tests
pass there.
rfc in
https://discourse.llvm.org/t/rfc-dynamic-type-profiling-and-optimizations-in-llvm/74600
---------
Co-authored-by: modiking <modiking213@gmail.com>
When LLVM_PROFILE_FILE is set incorrectly (e.g. multiple %c) and it
falls back to use `default.profraw` name, but continuous mode is still
set. This might cause signal bus in the following scenario.
LLVM_PROFILE_FILE is set incorrectly (with "%c%c") for process A and B.
Suppose A starts first and falls back to use `default.profraw` and
mmaped its file content to memory. Later B starts and also falls back to
use `default.profraw`, but it will truncate the file because online
merging is disable when reseting to `default.profraw`. When A tries to
update counter via mmaped memory, signal bus will occur.
This fixes it by disabling continuous mode when reset to
default.profraw.
Part 1 of 3. This includes the LLVM back-end processing and profile
reading/writing components. compiler-rt changes are included.
Differential Revision: https://reviews.llvm.org/D138846
In multi threaded application, it is possible for one thread to
terminate the program while another is flushing profile information. We
setup a signal mask to delay SIGKILL so that we can safely flush the
profile.
This patch setups the mask earlier: it reduces the window during which a
SIGKILL can end the computation prematurely.
This fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1850940, where a
profiled firefox was encountering several:
LLVM Profile Error: Failed to write file "default_*.profraw": Broken
pipe
Co-authored-by: serge-sans-paille <sguelton@mozilla.com>
This seems to cause Clang to crash, see comments on the code review. Reverting
until the problem can be investigated.
> Part 1 of 3. This includes the LLVM back-end processing and profile
> reading/writing components. compiler-rt changes are included.
>
> Differential Revision: https://reviews.llvm.org/D138846
This reverts commit a50486fd736ab2fe03fcacaf8b98876db77217a7.
Part 1 of 3. This includes the LLVM back-end processing and profile
reading/writing components. compiler-rt changes are included.
Differential Revision: https://reviews.llvm.org/D138846
In `initializeProfileForContinuousMode`, we have already locked the profile file when merging is enabled, so there's no need to lock the same file second time in `openFileForMerging`.
On Linux/Darwin, the locking the same file twice doesn't cause any problem. But on Windows, it causes the problem to hang forever.
With this minor fix, continuous mode seems working with online merging on Windows.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D154748
This fixes a warning about comparing mismatched types. Since `mmap()` already returns a `void *` use that as the pointer type for comparison.
Reviewed By: kyulee, zequanwu
Differential Revision: https://reviews.llvm.org/D120945
Existing code tended to assume that counters had type `uint64_t` and
computed size from the number of counters. Fix this code to directly
compute the counters size in number of bytes where possible. When the
number of counters is needed, use `__llvm_profile_counter_entry_size()`
or `getCounterTypeSize()`. In a later diff these functions will depend
on the profile mode.
Change the meaning of `DataSize` and `CountersSize` to make them more clear.
* `DataSize` (`CountersSize`) - the size of the data (counter) section in bytes.
* `NumData` (`NumCounters`) - the number of data (counter) entries.
Reviewed By: kyulee
Differential Revision: https://reviews.llvm.org/D116179
Replace D107203, because __llvm_profile_set_file_object is usually used when the
process doesn't have permission to open/create file. That patch trying to copy
from old profile to new profile contradicts with the usage.
Differential Revision: https://reviews.llvm.org/D108242
In the raw profile, binary ids immediately follow the header so when
computing counters offset we need to account for the new section.
Differential Revision: https://reviews.llvm.org/D108608
At least when compiling with gcc, this is not supported and will
result in errors when linking against the profiler runtime. Only
use the pragma comment linker based code with MSVC, but not with
a mingw toolchain. This also undoes D107620, which shouldn't be
relevant anymore.
Differential Revision: https://reviews.llvm.org/D108095
... and rename it to 'warnIfNonZero' to better-reflect what it actually
does.
The goal is to minimize the amount of logic that's conditionally
compiled under '#if __APPLE__'.
