Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve wording of uninitialized read warning #321

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

psalz
Copy link
Member

@psalz psalz commented Dec 19, 2024

The previous warning suggested to use no_init even for pure-consumer (read_only) accesses, which never made any sense.

Copy link

Check-perf-impact results: (000e2892abb21ddd1ae413a5c86d7d95)

❓ No new benchmark data submitted. ❓
Please re-run the microbenchmarks and include the results if your commit could potentially affect performance.

@psalz psalz force-pushed the improve-uninit-read-warning branch from 58591aa to 442b951 Compare December 19, 2024 11:03
@coveralls
Copy link

Pull Request Test Coverage Report for Build 12411400550

Details

  • 10 of 10 (100.0%) changed or added relevant lines in 1 file are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage remained the same at 95.05%

Totals Coverage Status
Change from base Build 12390656669: 0.0%
Covered Lines: 7096
Relevant Lines: 7201

💛 - Coveralls

Comment on lines +92 to +99
bool is_pure_consumer_access = true;
for(size_t i = 0; i < access_map.get_num_accesses(); ++i) {
const auto [b, mode] = access_map.get_nth_access(i);
if(b == bid && is_producer_mode(mode)) {
is_pure_consumer_access = false;
break;
}
}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is also just a heuristic btw; there could be an uninitialized read and an initialized write on the same buffer and it would print the no_init advice. Unfortunately I don't think this can be avoided unless we do the check on a per-accessor basis (which would mean separately evaluating each range mapper, followed by a region map query).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is still better than what we have now! ... and we should at some point improve the buffer_access_map interface so this can just be a std::any_of.

Copy link
Contributor

@GagaLP GagaLP left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new wording makes it more readable. Nice

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants