BSD Commit Log Search

Merge branch 'main' into users/ylzsx/r-tls-noie

Merge branch 'main' into users/meinersbur/flang_runtime_premerge

rebase

Created using spr 1.3.5-bogner

Merge branch 'users/chapuni/mcdc/nest/nest-base' into users/chapuni/mcdc/nest/trunk

Merge branch 'users/chapuni/mcdc/nest/bitmapaddr' into users/chapuni/mcdc/nest/nest-base

Conflicts:
        clang/test/CoverageMapping/mcdc-single-cond.cpp

Merge branch 'users/chapuni/mcdc/nest/tests' into users/chapuni/mcdc/nest/bitmapaddr

Merge branch 'users/chapuni/mcdc/nest/tests' into users/chapuni/mcdc/nest/mcdcstate

Merge branch 'users/chapuni/mcdc/nest/tests' into users/chapuni/mcdc/nest/lnot

Merge branch 'users/chapuni/mcdc/nest/tests' into users/chapuni/mcdc/nest/expect

Merge branch 'main' into users/chapuni/mcdc/nest/tests

run 'git merge main'

fix order

Created using spr 1.3.4

[𝘀𝗽𝗿] changes introduced through rebase

Created using spr 1.3.4

[skip ci]

Rebase

Created using spr 1.3.5

rebase

Created using spr 1.3.4

refactor

Created using spr 1.3.4

Address @DavidSpickett's comment

Created using spr 1.3.5-bogner

Merge branch 'main' of https://github.com/llvm/llvm-project into cbuffer-codegen5

Rebase, address comments, remove some extra graph-related code

Created using spr 1.3.5

rebase

Created using spr 1.3.4

Merge branch 'main' into obj2yaml/root-constants

[PGO] Fix incorrect count threshold calculation when 0% cutoff (#117359)

DefaultCutoffsData does not have an entry for the 0th percentile. As a
result, when the getEntryForPercentile method is called with a
percentile argument of 0, it returns a ProfileSummaryEntry for the 1st
percentile instead. This behavior affects the threshold calculations,
such as getHotCountThreshold, causing them to incorrectly identify some
sample profile counts as hot when they should not be.

This patch addresses the issue by handling the 0th percentile case in
the getEntryForPercentile method. This ensures that when the
-profile-summary-cutoff-hot (or -cold) option is set to 0, no sample
counts are treated as hot (or all sample counts are treated as cold).

Merge commit 'dd699c1333daeaea1c50c1506a66e9c7372afbb5' into users/meinersbur/irbuilder-extract

Merge commit '7fa2a83d1d18b49255e10e63bc7fead72026285b' into users/meinersbur/irbuilder-extract

Merge commit 'e2d1e2183a9615c669392eefcfe632cc0b59a649' into users/meinersbur/irbuilder-extract

Merge commit '41d5033eb162cb92b684855166cabfa3983b74c6^' into users/meinersbur/irbuilder-extract

Merge commit '6942c64e8128e4ccd891b813d0240f574f80f59e^' into users/meinersbur/irbuilder-extract-refactor

erge commit '343de6856e16b58bcbd16d479fc633f54e22fadc^' into users/meinersbur/irbuilder-extract-refactor

[llvm-profdata] Refactoring Sample Profile Reader to increase FDO build speed using MD5 as key to Sample Profile map

This is phase 1 of multiple planned improvements on the sample profile loader.   The major change is to use MD5 hash code ((instead of the function itself) as the key to look up the function offset table and the profiles, which significantly reduce the time it takes to construct the map.

The optimization is based on the fact that many practical sample profiles are using MD5 values for function names to reduce profile size, so we shouldn't need to convert the MD5 to a string and then to a SampleContext and use it as the map's key, because it's extremely slow.

Several changes to note:

(1) For non-CS SampleContext, if it is already MD5 string, the hash value will be its integral value, instead of hashing the MD5 again. In phase 2 this is going to be optimized further using a union to represent MD5 function (without converting it to string) and regular function names.

(2) The SampleProfileMap is a wrapper to *map<uint64_t, FunctionSamples>, while providing interface allowing using SampleContext as key, so that existing code still work. It will check for MD5 collision (unlikely but not too unlikely, since we only takes the lower 64 bits) and handle it to at least guarantee compilation correctness (conflicting old profile is dropped, instead of returning an old profile with inconsistent context). Other code should not try to use MD5 as key to access the map directly, because it will not be able to handle MD5 collision at all. (see exception at (5) )

(3) Any SampleProfileMap::emplace() followed by SampleContext assignment if newly inserted, should be replaced with SampleProfileMap::Create(), which does the same thing.

(4) Previously we ensure an invariant that in SampleProfileMap, the key is equal to the Context of the value, for profile map that is eventually being used for output (as in llvm-profdata/llvm-profgen). Since the key became MD5 hash, only the value keeps the context now, in several places where an intermediate SampleProfileMap is created, each new FunctionSample's context is set immediately after insertion, which is necessary to "remember" the context otherwise irretrievable.

(5) When reading a profile, we cache the MD5 values of all functions, because they are used at least twice (one to index into FuncOffsetTable, the other into SampleProfileMap, more if there are additional sections), in this case the SampleProfileMap is directly accessed with MD5 value so that we don't recalculate it each time (expensive)

Performance impact:

    [5 lines not shown]

Revert "[llvm-profdata] Refactoring Sample Profile Reader to increase FDO build speed using MD5 as key to Sample Profile map"

This reverts commit 66ba71d913df7f7cd75e92c0c4265932b7c93292.

Addressing issues found by:
https://lab.llvm.org/buildbot/#/builders/245/builds/11732
https://lab.llvm.org/buildbot/#/builders/187/builds/12251
https://lab.llvm.org/buildbot/#/builders/186/builds/11099
https://lab.llvm.org/buildbot/#/builders/182/builds/6976