All of these families were claiming to be a73 based, which was causing -mcpu/mtune=native to never use the newer features available to these cores. Goes through each and bumps the individual cores to their respective Big counterparts. Since this code path doesn't support big.little detection, there was already a precedent set with the Qualcomm line to choose the big cores only. Adds a comment on each line for the product's name that the part number refers to. Confirmed on-device and through Linux header naming convections. Additionally newer SoCs mix CPU implementer parts from multiple implementers. Both 0x41 (ARM) and 0x51 (Qualcomm) in the Snapdragon case This was causing a desync in information where the scan at the start to find the implementer would mismatch the part scan later on. Now scan for both implementer and part at the start so these stay in sync.
Details
- Reviewers
dmgreen - Group Reviewers
Restricted Project - Commits
- rG045d84f4e6d7: D94954: Fixes Snapdragon Kryo CPU core detection
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
This doesn't fully fix the issue on my end.
I'll need to try again, compiling a simple atomic op with -mcpu=native on my Snapdragon 865 board still did loadstore exclusive instead of CAS. while -mcpu=cortex-a77 does.
There was a desync between Implementer and Part scans.
Implementer would scan to the end of /proc/cpuinfo, setting the implementer to 0x41 (ARM) but then the StringSwitch loop would return the first definition it would find. Which was CPU part 0x805, which doesn't exist for implementer 0x41 because that was actually a 0x51 implementer part.
Moves the Part scan to the start alongside the Implementer scan so these two values stay in sync across platforms that mix implementers.
There are some tests in llvm/unittests/Support/Host.cpp. Can you add test for these cpu's and the multiple infos you were seeing? I suppose it now gets the info from the last one?
Adds unit test to ensure it pulls out cortex-a77 from a Snapdragon mixed implementer minimum cpuinfo.
Correct. It now pulls that last implementer/part pair from the cpuinfo. Which it was kind of sort of already doing, just in a strange desync'd manner that was broken if you mixed implementers.
In your commit the message does not include Reviewed by:. Many people agree that both Reviewed by: & Differential Revision: should be present. The Reviewed by: list indicates people who acknowledged the patch. (The Reviewers: list does not necessarily mean all the people on the list have acknowledged the patch so Reviewers: is mostly useless.)
arc amend can fetch the Phabricator summary and amend the local description.
You can install llvm/utils/git/pre-push.py to prevent accidental Summary:, Reviewers:, Subscribers: and Tags: in the presence of Differential Revision:.
This has mixed signals to me.
Looking at the recent commits, there is a smattering of commits putting this in the commit message or not.
Additionally they already have the differential review in the commit messages.
If this is to be enforced, it should first be added to the contributor guide which has nothing on the topic. https://llvm.org/docs/Contributing.html
And then there should be additional enforcement as a server-side git hook to block this from missing on the server side.
This is also a minor bugfix that has been merged for nearly a week now. Coming around at this point just to tell me this is just aggressive messaging.
Sorry, it was my mistake. The consensus is to have Differential Revision: . Reviewed by: is optional. Reviewers:/Tags:/Subscribers: cannot be added.
This is also a minor bugfix that has been merged for nearly a week now. Coming around at this point just to tell me this is just aggressive messaging.
I reported issues to Reviewed by: patches equally. I just checked - and this commit message is good. But for others, it is not late to tell them to improve for future commits. (And many people may not read relevant sentences https://llvm.org/docs/Contributing.html )