This is an archive of the discontinued LLVM Phabricator instance.

[Support] Change TrackingStatistic and NoopStatistic to use uint64_t instead of unsigned
ClosedPublic

Authored by mingmingl on Jun 17 2022, 10:02 AM.

Details

Summary

Passes could store large integers into stats, as a result of using block frequency counters. Using uint64_t gives a much smaller chance of overflow and reduces confusion. One example pass is block-placement-stats.


About binary size

For bin/clang, https://www.diffchecker.com/xZIbpmYz is a diff of bloaty bin/clang

the FILE SIZE and VM SIZE of bloaty (measured at MiB) doesn't change before and after this change; the .data section increases from 139Ki to 173Ki. Full bloaty output in [1]

[1] https://gist.github.com/minglotus-6/a9af947ab9d6ed120d87682b214c21ac is bloaty bin/clang with unsigned, and https://gist.github.com/minglotus-6/a9af947ab9d6ed120d87682b214c21ac is bloaty bin/clang with uint64_t, measured at the same base commit number, with and without this patch.

Diff Detail

Event Timeline

mingmingl created this revision.Jun 17 2022, 10:02 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 17 2022, 10:02 AM
Herald added a subscriber: hiraditya. · View Herald Transcript
mingmingl requested review of this revision.Jun 17 2022, 10:02 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 17 2022, 10:02 AM

I think this makes sense. Any chance to compare clang sizes with and without this change? I think it is fine to increase the size a bit as fixing the overflow problem is more important, but the number should still be useful.

llvm/unittests/ADT/StatisticTest.cpp
46

UINT64_C(0) may be better.

MaskRay accepted this revision.Jun 17 2022, 12:24 PM

[Stats] is an abbreviation of an uncommon tag [Statistics] . I'd use [Support] Change TrackingStatistic to use uint64_t instead of unsigned

We check 64-bit atomic support (CMake check_working_cxx_atomics64), so the new use is fine. It may be first time LLVMSupport uses it, though (not checked very carefully).

I'll suggest that postpone this to at least Monday afternoon (skipping weekend) to give other folks a chance to look.

This revision is now accepted and ready to land.Jun 17 2022, 12:24 PM

In struct Statistic from [1], change field value type from unsigned to uint64_t accordingly.

[1] llvm-project/mlir/lib/Pass/PassStatistics.cpp https://github.com/llvm/llvm-project/blob/86d5d34c72233f75165bc328d8c45979979d126a/mlir/lib/Pass/PassStatistics.cpp#L24

mingmingl retitled this revision from [Stats] Change Value type from unsigned to uint64_t. to [Support] Change TrackingStatistic to use uint64_t instead of unsigned.Jun 17 2022, 12:54 PM
mingmingl marked an inline comment as done.EditedJun 17 2022, 1:00 PM

I think this makes sense. Any chance to compare clang sizes with and without this change? I think it is fine to increase the size a bit as fixing the overflow problem is more important, but the number should still be useful.

Sure; it makes sense to me to measure binary size.

For bin/clang, https://www.diffchecker.com/xZIbpmYz is a diff of bloaty bin/clang

  • the FILE SIZE and VM SIZE of bloaty (measured at MiB) doesn't change before and after this change; the .data section increases from 139Ki to 173Ki. Full bloaty output in [1]

[1] https://gist.github.com/minglotus-6/a9af947ab9d6ed120d87682b214c21ac is bloaty bin/clang with unsigned, and https://gist.github.com/minglotus-6/a9af947ab9d6ed120d87682b214c21ac is bloaty bin/clang with uint64_t, measured at the same base commit number, with and without this patch.

[Stats] is an abbreviation of an uncommon tag [Statistics] . I'd use [Support] Change TrackingStatistic to use uint64_t instead of unsigned

We check 64-bit atomic support (CMake check_working_cxx_atomics64), so the new use is fine. It may be first time LLVMSupport uses it, though (not checked very carefully).

Thanks for checking check_working_cxx_atomics64.

I'll suggest that postpone this to at least Monday afternoon (skipping weekend) to give other folks a chance to look.

This is also what i'm planning to do. Will hold this patch over the (long) weekend and revisit it on Tuesday.

mingmingl updated this revision to Diff 438022.Jun 17 2022, 1:03 PM

In llvm/unittests/ADT/StatisticTest.cpp line 45, use UINT64_C(0) rather than 0ll as suggested.

mingmingl edited the summary of this revision. (Show Details)Jun 17 2022, 1:05 PM
mingmingl edited the summary of this revision. (Show Details)
mingmingl updated this revision to Diff 438029.Jun 17 2022, 1:28 PM

No change to patch content; 2 updates commit message (keep commit message and differential summary consistent, and append differential revision link as the last line of commit message).

You may click Edit Revision to edit the summary and then run arc amend to update local commit message with the summary.
This way you will not append an item to History.

mingmingl updated this revision to Diff 438155.Jun 18 2022, 3:19 PM
mingmingl retitled this revision from [Support] Change TrackingStatistic to use uint64_t instead of unsigned to [Support] Change TrackingStatistic and NoopStatistic to use uint64_t instead of unsigned.
  1. Change NoopStatistic to use uint64_t, to use consistent type for TrackingStatistic and NoopStatistic.
  1. Update uint64_t usage in polly sub-projects accordingly.
    • This is caught by premerge-test, and not covered by previous ninja check-all when polly wasn't specified in DLLVM_ENABLE_PROJECTS

You may click Edit Revision to edit the summary and then run arc amend to update local commit message with the summary.
This way you will not append an item to History.

Acknowledged.

MaskRay accepted this revision.Jun 19 2022, 12:06 PM
This revision was landed with ongoing or failed builds.Jun 22 2022, 10:12 AM
This revision was automatically updated to reflect the committed changes.
nikic added a subscriber: nikic.Jul 29 2022, 8:26 AM

We check 64-bit atomic support (CMake check_working_cxx_atomics64), so the new use is fine. It may be first time LLVMSupport uses it, though (not checked very carefully).

Not just LLVMSupport, from what I can tell this is the first time LLVM requires libatomic -- previously this was only needed to work around compiler bugs (e.g. GCC targeting RISCV incorrectly used libatomic in some cases). That libatomic is now required for all 32-bit targets is quite unfortunate.

Is there some way that a consumer statically linking LLVM can detect which libraries they need to link when cross-compiling? llvm-config has this information, but obviously it doesn't work when cross-compiling. The cmake exports don't seem to have the information (and having to parse cmake files to extract this would certainly be not great).