diff options
author | Rui Ueyama <ruiu@google.com> | 2015-10-26 16:20:00 +0000 |
---|---|---|
committer | Rui Ueyama <ruiu@google.com> | 2015-10-26 16:20:00 +0000 |
commit | df985afa149aa083eb6ab23872681fa4af15dbca (patch) | |
tree | dd7577c4f9bd1dbb103db720c6490a08c4db5577 /lldb/test/python_api/section/TestSectionAPI.py | |
parent | 83553d0cac09085ac9405ee171414a5a040e8e0f (diff) | |
download | bcm5719-llvm-df985afa149aa083eb6ab23872681fa4af15dbca.tar.gz bcm5719-llvm-df985afa149aa083eb6ab23872681fa4af15dbca.zip |
COFF: De-parallelize ICF for now.
There was a threading issue in the ICF code for COFF. That seems like
a venign bug in the sense that it doesn't produce an incorrect output,
but it oftentimes misses reducible sections. As a result, mergeable
sections could remain in outputs, which makes the output nondeterministic.
Basically the algorithm we are using for ICF is this: We group sections
so that identical sections will eventually be in the same group. Initially,
all sections are in one group. We split the group by relocation targets
until we get a convergence (if relocation targets are in different gruops,
the sections are different). Once a group is split, they will never be
merged.
Each section has a group ID. That variable itself is atomic, so there's
no threading issue at the level that we can use thread sanitizer.
The point is, when we split a group, we re-assign new group IDs to group
of sections. That are multiple separate writes to atomic varaibles.
Thus, splitting a group is not an atomic operation, and there's a small
chance that the other thread observes inconsistent group IDs.
Over-splitting is always "safe", so it will never create incorrect output.
I suspect that the nondeterminism stems from that point. However, I
cannot prove or fix that at this moment, so I'm going to avoid using
threads here.
llvm-svn: 251300
Diffstat (limited to 'lldb/test/python_api/section/TestSectionAPI.py')
0 files changed, 0 insertions, 0 deletions