| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
Revert "Revert "[Coverage] Emit gap region between statements if first statements contains terminate statements."" Reland with update on test case ContinuousSyncmode/basic.c. This reverts commit fe5c2c3ca682b140dd5e640e75948363b6b25ef9. | 5 年前 | |
[profile] Add a mode to continuously sync counter updates to a file Add support for continuously syncing profile counter updates to a file. The motivation for this is that programs do not always exit cleanly. On iOS, for example, programs are usually killed via a signal from the OS. Running atexit() handlers after catching a signal is unreliable, so some method for progressively writing out profile data is necessary. The approach taken here is to mmap() the __llvm_prf_cnts section onto a raw profile. To do this, the linker must page-align the counter and data sections, and the runtime must ensure that counters are mapped to a page-aligned offset within a raw profile. Continuous mode is (for the moment) incompatible with the online merging mode. This limitation is lifted in https://reviews.llvm.org/D69586. Continuous mode is also (for the moment) incompatible with value profiling, as I'm not sure whether there is interest in this and the implementation may be tricky. As I have not been able to test extensively on non-Darwin platforms, only Darwin support is included for the moment. However, continuous mode may "just work" without modification on Linux and some UNIX-likes. AIUI the default value for the GNU linker's --section-alignment flag is set to the page size on many systems. This appears to be true for LLD as well, as its no_nmagic option is on by default. Continuous mode will not "just work" on Fuchsia or Windows, as it's not possible to mmap() a section on these platforms. There is a proposal to add a layer of indirection to the profile instrumentation to support these platforms. rdar://54210980 Differential Revision: https://reviews.llvm.org/D68351 | 6 年前 | |
[profile] Fix buffer overrun when parsing %c in filename string Fix a buffer overrun that can occur when parsing '%c' at the end of a filename pattern string. rdar://74571261 Reviewed By: kastiglione Differential Revision: https://reviews.llvm.org/D97239 | 5 年前 | |
[profile] Skip mmap() if there are no counters If there are no counters, an mmap() of the counters section would fail due to the size argument being too small (EINVAL). rdar://78175925 Differential Revision: https://reviews.llvm.org/D102735 | 5 年前 | |
[profile] Suppress spurious 'expected profile to require unlock' warning In %c (continuous sync) mode, avoid attempting to unlock an already-unlocked profile. The profile is only locked when profile merging is enabled. | 5 年前 | |
[test] Deflake test/profile/ContinuousSyncMode/online-merging.c This test spawns 32 child processes which race to update counters on shared memory pages. On some Apple-internal machines, two processes race to perform an update in approximately 0.5% of the test runs, leading to dropped counter updates. Deflake the test by using atomic increments. Tested with: $ for I in $(seq 1 1000); do echo ":: Test run $I..."; ./bin/llvm-lit projects/compiler-rt/test/profile/Profile-x86_64h/ContinuousSyncMode/online-merging.c -av || break; done rdar://64956774 | 5 年前 | |
[profile] Support counter relocation at runtime This is an alternative to the continous mode that was implemented in D68351. This mode relies on padding and the ability to mmap a file over the existing mapping which is generally only available on POSIX systems and isn't suitable for other platforms. This change instead introduces the ability to relocate counters at runtime using a level of indirection. On every counter access, we add a bias to the counter address. This bias is stored in a symbol that's provided by the profile runtime and is initially set to zero, meaning no relocation. The runtime can mmap the profile into memory at abitrary location, and set bias to the offset between the original and the new counter location, at which point every subsequent counter access will be to the new location, which allows updating profile directly akin to the continous mode. The advantage of this implementation is that doesn't require any special OS support. The disadvantage is the extra overhead due to additional instructions required for each counter access (overhead both in terms of binary size and performance) plus duplication of counters (i.e. one copy in the binary itself and another copy that's mmapped). Differential Revision: https://reviews.llvm.org/D69740 | 6 年前 | |
Revert "Revert "[Coverage] Emit gap region between statements if first statements contains terminate statements."" Reland with update on test case ContinuousSyncmode/basic.c. This reverts commit fe5c2c3ca682b140dd5e640e75948363b6b25ef9. | 5 年前 | |
Revert "[compiler-rt][Profile] Disable test on Arm/AArch64 Linux" This reverts commit 8b86f8a3256a59cbaa12858cb0842025d48f549f. The inconsistent behaviour has been fixed with 5e50d3073a5ead122a731580ded3f1cb3c21ee54. | 4 年前 | |
[profile] Support counter relocation at runtime This is an alternative to the continous mode that was implemented in D68351. This mode relies on padding and the ability to mmap a file over the existing mapping which is generally only available on POSIX systems and isn't suitable for other platforms. This change instead introduces the ability to relocate counters at runtime using a level of indirection. On every counter access, we add a bias to the counter address. This bias is stored in a symbol that's provided by the profile runtime and is initially set to zero, meaning no relocation. The runtime can mmap the profile into memory at abitrary location, and set bias to the offset between the original and the new counter location, at which point every subsequent counter access will be to the new location, which allows updating profile directly akin to the continous mode. The advantage of this implementation is that doesn't require any special OS support. The disadvantage is the extra overhead due to additional instructions required for each counter access (overhead both in terms of binary size and performance) plus duplication of counters (i.e. one copy in the binary itself and another copy that's mmapped). Differential Revision: https://reviews.llvm.org/D69740 | 6 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 5 年前 | ||
| 6 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 6 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 6 年前 |