Emit coverage mappings for all modules #32216
Conversation
|
Updated with a test |
Previously in WMO builds where IR was multithreaded only the primary module would emit the coverage mapping leading to only the first object file to have the __llvm_covmap section. This change emits coverage for all modules so they are correctly reflected in the final coverage report.
keith
force-pushed
the
ks/coverage-modules
branch
from
aa7258c to
8215ea1
Compare
|
I don't have permissions or anything so do you mind landing this? |
|
@swift-ci smoke test and merge |
|
I can't force merge, but I've tried to kick off a CI job which should integrate this. |
|
totally, thanks! |
|
Looks like that comment didn't trigger anything, maybe related to yesterday's issues? |
|
@swift-ci smoke test and merge |
|
Let's try again. This time the 'Test and Merge (smoke test)' job looks like it got queued. As of this morning, there were still HVAC issues in the server room so this may take a few attempts -- sorry for the delay. |
|
no worries, thanks! |
|
This seems to have caused a regression on the Windows builders: |
|
|
||
| // SINGLE-OBJECT: llvm_coverage_mapping = | ||
|
|
||
| // RUN: %target-swift-frontend -profile-generate -profile-coverage-mapping -num-threads 2 -emit-ir %S/Inputs/coverage_num_threads1.swift %S/Inputs/coverage_num_threads2.swift | %FileCheck %s -check-prefix=MULTIPLE-OBJECTS --implicit-check-not="llvm_coverage_mapping =" |
There was a problem hiding this comment.
Is there some way other than -num-threads to control how files are split up into different modules (maybe @eeckstein knows)?
The issue on Windows appears to be that only the IR for one of the modules is printed out. The first '@__llvm_coverage_mapping =' definition is matched, but the second isn't.
There was a problem hiding this comment.
If you're able to quickly test this (I'm spinning up a windows env now) does changing the thread count to 1 change this behavior? I originally did 2 just to make it super clear it was going through the multi-threaded path but 1 also does, so if that affected this that test would still be valid.
There was a problem hiding this comment.
I don't have access to a Windows environment right now. And I'm not sure I follow your comment here: why should swift only emit the IR for one module, given two source files and -num-threads=2?
There was a problem hiding this comment.
Oh I'm definitely not saying it should, it sounds like a bug in -emit-ir only for windows to me, so I was just thinking maybe 1 would avoid that.
There was a problem hiding this comment.
For historians this was re-merged here #32352
Previously in WMO builds where IR was multithreaded only the
primary module would emit the coverage mapping leading to only the first
object file to have the __llvm_covmap section. This change emits
coverage for all modules so they are correctly reflected in the final
coverage report.
This fixes https://forums.swift.org/t/code-coverage-with-wmo/32561/
Fixes rdar://42562585
Fixes rdar://42562307