This is an archive of the discontinued LLVM Phabricator instance.

[Support] Move getHostNumPhysicalCores to Threading.h
ClosedPublic

Authored by lenary on Nov 11 2022, 6:39 AM.

Details

Summary

This change is focussed on simplifying Support/Host.h to only do
target detection. In this case, this function is close in usage to
existing functions in Support/Threading.h, so I moved it into there.
The function is also renamed to llvm::get_physical_cores() to match
the style of threading's functions.

The big change here is that now if you have threading disabled,
llvm::get_physical_cores() will return -1, as if it had not been able
to work out the right info. This is due to how Threading.cpp includes
OS-specific code/headers. This seems ok, as if threading is disabled,
LLVM should not need to know the number of physical cores.

Diff Detail

Event Timeline

lenary created this revision.Nov 11 2022, 6:39 AM
lenary requested review of this revision.Nov 11 2022, 6:39 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptNov 11 2022, 6:39 AM
tmatheson accepted this revision.Nov 11 2022, 8:33 AM
This revision is now accepted and ready to land.Nov 11 2022, 8:33 AM

Makes sense since it is so similar to get_cpus() and is only used in Threading.

fpetrogalli added inline comments.
llvm/unittests/Support/Host.cpp
32–33

Is this needed?

411

I think you can remove the class HostTest and convert the test fixture into just TEST( instead of TEST_F(. It is kind of awkward to have this: class HostTest : public testing::Test {};

llvm/unittests/Support/Threading.cpp
42

I don't think you need to derive from testing:Test? The functionality of `isSupportedArchAndOS could be achieved just with a function.

lenary updated this revision to Diff 477912.Nov 25 2022, 4:17 AM
lenary edited the summary of this revision. (Show Details)
lenary marked 2 inline comments as done.
lenary added inline comments.Nov 25 2022, 4:17 AM
llvm/unittests/Support/Host.cpp
32–33

My original intention was to do the minimal changes required to just move the code.

It's not technically needed, so I will remove it.

411

Yeah, Will do.

llvm/unittests/Support/Threading.cpp
42

Yes, will do.

fpetrogalli added inline comments.Nov 25 2022, 4:24 AM
llvm/unittests/Support/Host.cpp
32–33

Yeah, I totally get the idea of doing minimal changes. Juts mention in the commit message that you have some extra cleanup that is not strictly needed for the major changes of the patch, so that people blaming the change can understand why that was done.

lenary added inline comments.Nov 25 2022, 4:30 AM
llvm/unittests/Support/Host.cpp
32–33

So, I forgot to submit this comment *before* I submitted the changes. If you're happy with how the patch looks now, +2 and I'll land it.

fpetrogalli accepted this revision.Nov 25 2022, 4:33 AM

LGTM. Thank you @lenary

This revision was landed with ongoing or failed builds.Nov 25 2022, 4:51 AM
This revision was automatically updated to reflect the committed changes.
fhahn added a subscriber: fhahn.Nov 25 2022, 6:14 AM

Unfortunately it looks like this commit breaks building on ARM64 macOS. I reverted the change for now and added more details on the error in the revert commit.

Unfortunately it looks like this commit breaks building on ARM64 macOS. I reverted the change for now and added more details on the error in the revert commit.

Thanks for reverting. I hadn't seen any buildbot messages about this until now. It's annoying there's no mac pre-merge testing.

fhahn added a comment.Nov 25 2022, 6:26 AM

Unfortunately it looks like this commit breaks building on ARM64 macOS. I reverted the change for now and added more details on the error in the revert commit.

Thanks for reverting. I hadn't seen any buildbot messages about this until now. It's annoying there's no mac pre-merge testing.

FYI macOS testing is happening on https://green.lab.llvm.org. The failing build is https://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/32875/console. From the log it looks like the bot didn't send an email though. Just to double check, you didn't receive an email notification about this?

(it looks like this job should have sent an email: https://green.lab.llvm.org/green/job/clang-stage1-RA/32031/console)

Yeah, sorry, no email. I'll check with colleagues to see if other people do get emails from this CI instance.

fhahn added a comment.Nov 25 2022, 6:51 AM

(it looks like this job should have sent an email: https://green.lab.llvm.org/green/job/clang-stage1-RA/32031/console)

Yeah, sorry, no email. I'll check with colleagues to see if other people do get emails from this CI instance.

Thanks for confirming, I'll let the maintainers know.

lenary reopened this revision.Nov 25 2022, 8:28 AM
This revision is now accepted and ready to land.Nov 25 2022, 8:28 AM
lenary updated this revision to Diff 477975.Nov 25 2022, 8:28 AM
lenary edited the summary of this revision. (Show Details)
lenary added a subscriber: MaskRay.Nov 25 2022, 8:29 AM

New version, which changes how the move works a bit. I've updated the description with the caveats, so this is now definitely not NFC.

I'm looking for re-review, and maybe input from @MaskRay who has made some minor cleanups in this code recently.

tmatheson accepted this revision.Nov 25 2022, 11:42 AM

One thought about returning -1 but otherwise LGTM

llvm/lib/Support/Threading.cpp
59

It looks like this is the only place get_physical_cores is used, and if the number is unknown or threading is disabled MaxThreadCount is just set to 1. Would it not make sense to change get_physical_cores to return 1, like compute_thread_count?

lenary marked 3 inline comments as done.Nov 28 2022, 1:50 AM

Going to attempt to land this again today.

llvm/lib/Support/Threading.cpp
59

I'd rather keep the unknown semantic, so it's clearer why someone is getting the answer they are.

This revision was landed with ongoing or failed builds.Nov 29 2022, 5:14 AM
This revision was automatically updated to reflect the committed changes.
lenary marked an inline comment as done.

Looks like tests need updating for that new -1 return value: https://lab.llvm.org/buildbot/#/builders/178/builds/3419

That bot builds with threading disabled.

Looks like tests need updating for that new -1 return value: https://lab.llvm.org/buildbot/#/builders/178/builds/3419

That bot builds with threading disabled.

Thanks for letting me know. I'm thinking about the fix, likely an update to isThreadingSupportedArchAndOs.

Looks like tests need updating for that new -1 return value: https://lab.llvm.org/buildbot/#/builders/178/builds/3419

That bot builds with threading disabled.

Thanks for letting me know. I'm thinking about the fix, likely an update to isThreadingSupportedArchAndOs.

https://reviews.llvm.org/D139015 Patch here