Refactor getHostCPUName to allow testing on non-native hardware.

[kristof.beyls]

Summary

This refactors getHostCPUName so that for the architectures that get the
host cpu info on linux from /proc/cpuinfo, the /proc/cpuinfo parsing
logic is present in the build, even if it wasn't built on a linux system
for that architecture.

Since the code is present in the build, we can then test that code also
on other systems, i.e. we don't need to have buildbots setup for all
architectures on linux to be able to test this. Instead, developers will
test this as part of the regression test run.

As an example, a unit test is added to test getHostCPUName for a
Cortex-A9 processor running linux. A unit test is preferred over a
lit-based test, since the expectation is that in the future, the
functionality here will grow over what can be tested with "llc
-mcpu=native".

This is a preparation step to enable implementing the range of
improvements discussed on PR30516, such as adding AArch64 support,
support for big.LITTLE systems, reducing code duplication.

[rengolin]

include/llvm/Support/Host.h

83 ↗

(On Diff #92607)

These don't need to be virtual, do they? They could even be static.

unittests/Support/Host.cpp

53 ↗

(On Diff #92607)

Do we have tests for the other platforms?

90 ↗

(On Diff #92607)

There are a number of different ways to find cpu names on ARM cpuinfo, and it would be good to know that they're all working. Maybe having a few different small snippets, instead of one large and redundant one?

[kristof.beyls]

include/llvm/Support/Host.h

83 ↗

(On Diff #92607)

Ah right.
To be able to mock methods, they need to be virtual, so a Mock class can override them.
There are work-arounds to be able to mock non-virtual methods, but the work-arounds are worse than using virtual methods, IMHO.
See https://github.com/google/googletest/blob/master/googlemock/docs/CookBook.md, section "Mocking Nonvirtual Methods".

That being said, indeed, probably the getHostCPUName_xxx methods can be static non-virtual, as I don't see how these would need to be mocked.

unittests/Support/Host.cpp

50 ↗

(On Diff #92607)

No need to mock getHostCPUName_powerpc here.

53 ↗

(On Diff #92607)

Not at this point. I don't think this patch needs to introduce them, just make it easy for platform experts to add them in the test framework this patch introduces.

90 ↗

(On Diff #92607)

I imagine that over time, we'll add more tests and that most tests will uses a small snippet.
But, for example, in the future to be able to test big.LITTLE, probably it's best to use most of the /proc/cpuinfo content.
Also, right now, the implementation only actually reads the first 1024 bytes. When fixing that, we'll need a test with cpuinfo content larger than 1024 bytes.

In summary, in this patch I'm just aiming to demonstrate that it becomes possible to test this functionality also on other platforms, where before that wasn't possible. As a first test, I thought a simple full /proc/cpuinfo from a real system makes it slightly easier to read and understand rather than a further cut down input.

[rengolin]

include/llvm/Support/Host.h

83 ↗

(On Diff #92607)

Makes sense...

unittests/Support/Host.cpp

50 ↗

(On Diff #92607)

Right.

53 ↗

(On Diff #92607)

Ok.

90 ↗

(On Diff #92607)

Sure, but in this case you just need to look at 0x09. :)

I mean, at this moment, it would be more value to have a few strings and testing for different CPUs than the whole string testing for a single CPU.

[hfinkel]

I'm curious why you chose to take this approach rather than add some option that allows us to change the file name being read? If we do that, then we can test this with lit tests. I generally think of our practice as using mocking, and unit tests in general, for cases where lit tests aren't practical (or, to put it another way, the infrastructure necessary to enable them is more complicated than unit testing in C++). This does not seem to be the case here. It seems straightforward to make -proc-cpuinfo-file=/foo/bar/cpuinfo.txt (modulo bikeshed) work.

As I recall, there are several other places in Clang where this is also a problem (we have hard-coded file names for /etc/lsb-release, /etc/redhat-release, etc.).

[kristof.beyls]

In D31236#707462, @hfinkel wrote:

I'm curious why you chose to take this approach rather than add some option that allows us to change the file name being read? If we do that, then we can test this with lit tests. I generally think of our practice as using mocking, and unit tests in general, for cases where lit tests aren't practical (or, to put it another way, the infrastructure necessary to enable them is more complicated than unit testing in C++). This does not seem to be the case here. It seems straightforward to make -proc-cpuinfo-file=/foo/bar/cpuinfo.txt (modulo bikeshed) work.

As I recall, there are several other places in Clang where this is also a problem (we have hard-coded file names for /etc/lsb-release, /etc/redhat-release, etc.).

I honestly hadn't thought this could fit in our lit testing framework. But maybe it could be made to do so as you outline above.
I see that tools/clang/unittests/Driver/DistroTest.cpp uses unittests with vfs::InMemoryFileSystem objects to mock the contents of /etc/lsb-release etc. I wasn't aware of the approach taken there, I'll take a closer look.

I think the main issue with a -proc-cpuinfo-file=%s command line option might be in which tool to attach it to. I guess it would have to be llc, run with -mcpu=native, and then somehow detecting the cpu it would set for code generation.

I think that might work for current functionality (returning a single CPU), but when we're trying to extend this to big.LITTLE systems, and introducing a call like getHostCPUNames(), returning all different cores in the system, I'm not sure anymore if it would be easily tested using "llc -mcpu=native", as it's unclear which core to pick for "native". FWIW, I expect getHostCPUNames() to initially mainly be used by JIT engines and they may make different choices than ahead-of-time compilers with -mcpu=native.

I'll look into this a bit further, but at the moment my feel is that testing via llc -mcpu=native may be too indirect for e.g. extending this API to big.LITTLE systems. I'm not sure if there is another tool already where we could test closer to getHostCPUName, but I don't think so.

[hfinkel]

In D31236#707538, @kristof.beyls wrote:

In D31236#707462, @hfinkel wrote:

I'm curious why you chose to take this approach rather than add some option that allows us to change the file name being read? If we do that, then we can test this with lit tests. I generally think of our practice as using mocking, and unit tests in general, for cases where lit tests aren't practical (or, to put it another way, the infrastructure necessary to enable them is more complicated than unit testing in C++). This does not seem to be the case here. It seems straightforward to make -proc-cpuinfo-file=/foo/bar/cpuinfo.txt (modulo bikeshed) work.

As I recall, there are several other places in Clang where this is also a problem (we have hard-coded file names for /etc/lsb-release, /etc/redhat-release, etc.).

I honestly hadn't thought this could fit in our lit testing framework. But maybe it could be made to do so as you outline above.
I see that tools/clang/unittests/Driver/DistroTest.cpp uses unittests with vfs::InMemoryFileSystem objects to mock the contents of /etc/lsb-release etc. I wasn't aware of the approach taken there, I'll take a closer look.

I think the main issue with a -proc-cpuinfo-file=%s command line option might be in which tool to attach it to. I guess it would have to be llc, run with -mcpu=native, and then somehow detecting the cpu it would set for code generation.

I think that might work for current functionality (returning a single CPU), but when we're trying to extend this to big.LITTLE systems, and introducing a call like getHostCPUNames(), returning all different cores in the system, I'm not sure anymore if it would be easily tested using "llc -mcpu=native", as it's unclear which core to pick for "native". FWIW, I expect getHostCPUNames() to initially mainly be used by JIT engines and they may make different choices than ahead-of-time compilers with -mcpu=native.

I'll look into this a bit further, but at the moment my feel is that testing via llc -mcpu=native may be too indirect for e.g. extending this API to big.LITTLE systems. I'm not sure if there is another tool already where we could test closer to getHostCPUName, but I don't think so.

Okay. I agree, for heterogeneous environments where '-mcpu=native' does not fully express the data you need, this doing it this way can make more sense.

[tstellar]

In D31236#707538, @kristof.beyls wrote:

In D31236#707462, @hfinkel wrote:

I'm curious why you chose to take this approach rather than add some option that allows us to change the file name being read? If we do that, then we can test this with lit tests. I generally think of our practice as using mocking, and unit tests in general, for cases where lit tests aren't practical (or, to put it another way, the infrastructure necessary to enable them is more complicated than unit testing in C++). This does not seem to be the case here. It seems straightforward to make -proc-cpuinfo-file=/foo/bar/cpuinfo.txt (modulo bikeshed) work.

As I recall, there are several other places in Clang where this is also a problem (we have hard-coded file names for /etc/lsb-release, /etc/redhat-release, etc.).

I honestly hadn't thought this could fit in our lit testing framework. But maybe it could be made to do so as you outline above.
I see that tools/clang/unittests/Driver/DistroTest.cpp uses unittests with vfs::InMemoryFileSystem objects to mock the contents of /etc/lsb-release etc. I wasn't aware of the approach taken there, I'll take a closer look.

I think the main issue with a -proc-cpuinfo-file=%s command line option might be in which tool to attach it to. I guess it would have to be llc, run with -mcpu=native, and then somehow detecting the cpu it would set for code generation.

llc -version prints the Host CPU name, so you could just check the output of that.

I think that might work for current functionality (returning a single CPU), but when we're trying to extend this to big.LITTLE systems, and introducing a call like getHostCPUNames(), returning all different cores in the system, I'm not sure anymore if it would be easily tested using "llc -mcpu=native", as it's unclear which core to pick for "native". FWIW, I expect getHostCPUNames() to initially mainly be used by JIT engines and they may make different choices than ahead-of-time compilers with -mcpu=native.

I'll look into this a bit further, but at the moment my feel is that testing via llc -mcpu=native may be too indirect for e.g. extending this API to big.LITTLE systems. I'm not sure if there is another tool already where we could test closer to getHostCPUName, but I don't think so.

[kristof.beyls]

• By refactoring a little bit more, it became possible to test using a regular unit test, not having to use a mock, which makes the test a lot cleaner.
• During review discussions with Hal, it become clear that it's probably best to stick to unit testing rather than using lit-based testing for this feature.

[kristof.beyls]

. Added a few short tests for a few more cores.

[rengolin]

LGTM. Thanks!

[chandlerc]

llvm/trunk/include/llvm/Support/Host.h

80–85

Capitalize 'helper' to make the comment prose.

Also, we more commonly use a 'detail' or 'internal' namespace. That would seem more consistent here.

And please follow the normal naming conventions rather than using a '_<arch>' suffix. Perhaps: getHostCPUNameForPowerPC, getHostCPUNameForARM, and getHostCPUNameForS390x.

[kristof.beyls]

llvm/trunk/include/llvm/Support/Host.h

80–85

Thanks for the feedback!
I tried to fix those issues in r299062, which resulted in the windows builds breaking, due to error messages like the following:

C:\Buildbot\Slave\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\include\llvm/ADT/DenseSet.h(215): error C2872: 'detail': ambiguous symbol
C:\Buildbot\Slave\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\include\llvm/Support/Chrono.h(78): note: could be 'llvm::detail'
C:\Buildbot\Slave\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\include\llvm/Support/Host.h(80): note: or       'llvm::sys::detail'

A few attempts at fixing the Windows builds by fixing the issues reported in the buildbot logs showed that every fix just uncovered more "ambiguous symbol errors", so I reverted the changes.
I'll probably need to investigate if introducing an llvm::sys::detail namespace is still a good idea (which means the "detail::xxx" syntaxes in quite a few places will need to be disambiguated to "llvm::detail::xxx"); or if an alternative solution needs to be found.

[kristof.beyls]

llvm/trunk/include/llvm/Support/Host.h

80–85

This has landed now, together with a series of namespace pollution cleanups that were necessary to unbreak the windows bots.
Main commit in r299211; namespace cleanups in r299203, r299218, r299222 and r299224.

llvm/trunk/include/llvm/Support/Host.h

 // Methods for querying the nature of the host machine.
 //
 //===----------------------------------------------------------------------===//
 
 #ifndef LLVM_SUPPORT_HOST_H
 #define LLVM_SUPPORT_HOST_H
 
 #include "llvm/ADT/StringMap.h"
+#include "llvm/Support/MemoryBuffer.h"
 
 #if defined(__linux__) || defined(__GNU__) || defined(__HAIKU__)
 #include <endian.h>
 #elif defined(_AIX)
 #include <sys/machine.h>
 #else
 #if !defined(BYTE_ORDER) && !defined(LLVM_ON_WIN32)
 #include <machine/endian.h>
#endif
   ///
   /// \return - True on success.
   bool getHostCPUFeatures(StringMap<bool> &Features);
 
   /// Get the number of physical cores (as opposed to logical cores returned
   /// from thread::hardware_concurrency(), which includes hyperthreads).
   /// Returns -1 if unknown for the current host system.
   int getHostNumPhysicalCores();
+
+  /// helper functions to extract HostCPUName from /proc/cpuinfo on linux.
+  namespace LinuxReadCpuInfo {
+  StringRef getHostCPUName_powerpc(const StringRef &ProcCpuinfoContent);
+  StringRef getHostCPUName_arm(const StringRef &ProcCpuinfoContent);
+  StringRef getHostCPUName_s390x(const StringRef &ProcCpuinfoContent);
+  }
 }
 }
 
 #endif

llvm/trunk/lib/Support/Host.cpp

 //===----------------------------------------------------------------------===//
 //
 //  Implementations of the CPU detection routines
 //
 //===----------------------------------------------------------------------===//
 
 using namespace llvm;
 
-#if defined(__linux__)
-static ssize_t LLVM_ATTRIBUTE_UNUSED readCpuInfo(void *Buf, size_t Size) {
-  // Note: We cannot mmap /proc/cpuinfo here and then process the resulting
-  // memory buffer because the 'file' has 0 size (it can be read from only
-  // as a stream).
-
-  int FD;
-  std::error_code EC = sys::fs::openFileForRead("/proc/cpuinfo", FD);
-  if (EC) {
-    DEBUG(dbgs() << "Unable to open /proc/cpuinfo: " << EC.message() << "\n");
-    return -1;
+static std::unique_ptr<llvm::MemoryBuffer>
+    LLVM_ATTRIBUTE_UNUSED getProcCpuinfoContent() {
+  llvm::ErrorOr<std::unique_ptr<llvm::MemoryBuffer>> Text =
+      llvm::MemoryBuffer::getFileAsStream("/proc/cpuinfo");
+  if (std::error_code EC = Text.getError()) {
+    llvm::errs() << "Can't read "
+                 << "/proc/cpuinfo: " << EC.message() << "\n";
+    return nullptr;
   }
-  int Ret = read(FD, Buf, Size);
-  int CloseStatus = close(FD);
-  if (CloseStatus)
-    return -1;
-  return Ret;
+  return std::move(*Text);
+}
+
+StringRef sys::LinuxReadCpuInfo::getHostCPUName_powerpc(
+    const StringRef &ProcCpuinfoContent) {
+  // Access to the Processor Version Register (PVR) on PowerPC is privileged,
+  // and so we must use an operating-system interface to determine the current
+  // processor type. On Linux, this is exposed through the /proc/cpuinfo file.
+  const char *generic = "generic";
+
+  // The cpu line is second (after the 'processor: 0' line), so if this
+  // buffer is too small then something has changed (or is wrong).
+  StringRef::const_iterator CPUInfoStart = ProcCpuinfoContent.begin();
+  StringRef::const_iterator CPUInfoEnd = ProcCpuinfoContent.end();
+
+  StringRef::const_iterator CIP = CPUInfoStart;
+
+  StringRef::const_iterator CPUStart = 0;
+  size_t CPULen = 0;
+
+  // We need to find the first line which starts with cpu, spaces, and a colon.
+  // After the colon, there may be some additional spaces and then the cpu type.
+  while (CIP < CPUInfoEnd && CPUStart == 0) {
+    if (CIP < CPUInfoEnd && *CIP == '\n')
+      ++CIP;
+
+    if (CIP < CPUInfoEnd && *CIP == 'c') {
+      ++CIP;
+      if (CIP < CPUInfoEnd && *CIP == 'p') {
+        ++CIP;
+        if (CIP < CPUInfoEnd && *CIP == 'u') {
+          ++CIP;
+          while (CIP < CPUInfoEnd && (*CIP == ' ' || *CIP == '\t'))
+            ++CIP;
+
+          if (CIP < CPUInfoEnd && *CIP == ':') {
+            ++CIP;
+            while (CIP < CPUInfoEnd && (*CIP == ' ' || *CIP == '\t'))
+              ++CIP;
+
+            if (CIP < CPUInfoEnd) {
+              CPUStart = CIP;
+              while (CIP < CPUInfoEnd && (*CIP != ' ' && *CIP != '\t' &&
+                                          *CIP != ',' && *CIP != '\n'))
+                ++CIP;
+              CPULen = CIP - CPUStart;
+            }
+          }
+        }
+      }
+    }
+
+    if (CPUStart == 0)
+      while (CIP < CPUInfoEnd && *CIP != '\n')
+        ++CIP;
+  }
+
+  if (CPUStart == 0)
+    return generic;
+
+  return StringSwitch<const char *>(StringRef(CPUStart, CPULen))
+      .Case("604e", "604e")
+      .Case("604", "604")
+      .Case("7400", "7400")
+      .Case("7410", "7400")
+      .Case("7447", "7400")
+      .Case("7455", "7450")
+      .Case("G4", "g4")
+      .Case("POWER4", "970")
+      .Case("PPC970FX", "970")
+      .Case("PPC970MP", "970")
+      .Case("G5", "g5")
+      .Case("POWER5", "g5")
+      .Case("A2", "a2")
+      .Case("POWER6", "pwr6")
+      .Case("POWER7", "pwr7")
+      .Case("POWER8", "pwr8")
+      .Case("POWER8E", "pwr8")
+      .Case("POWER8NVL", "pwr8")
+      .Case("POWER9", "pwr9")
+      .Default(generic);
+}
+
+StringRef sys::LinuxReadCpuInfo::getHostCPUName_arm(
+    const StringRef &ProcCpuinfoContent) {
+  // The cpuid register on arm is not accessible from user space. On Linux,
+  // it is exposed through the /proc/cpuinfo file.
+
+  // Read 1024 bytes from /proc/cpuinfo, which should contain the CPU part line
+  // in all cases.
+  SmallVector<StringRef, 32> Lines;
+  ProcCpuinfoContent.split(Lines, "\n");
+
+  // Look for the CPU implementer line.
+  StringRef Implementer;
+  for (unsigned I = 0, E = Lines.size(); I != E; ++I)
+    if (Lines[I].startswith("CPU implementer"))
+      Implementer = Lines[I].substr(15).ltrim("\t :");
+
+  if (Implementer == "0x41") // ARM Ltd.
+    // Look for the CPU part line.
+    for (unsigned I = 0, E = Lines.size(); I != E; ++I)
+      if (Lines[I].startswith("CPU part"))
+        // The CPU part is a 3 digit hexadecimal number with a 0x prefix. The
+        // values correspond to the "Part number" in the CP15/c0 register. The
+        // contents are specified in the various processor manuals.
+        return StringSwitch<const char *>(Lines[I].substr(8).ltrim("\t :"))
+            .Case("0x926", "arm926ej-s")
+            .Case("0xb02", "mpcore")
+            .Case("0xb36", "arm1136j-s")
+            .Case("0xb56", "arm1156t2-s")
+            .Case("0xb76", "arm1176jz-s")
+            .Case("0xc08", "cortex-a8")
+            .Case("0xc09", "cortex-a9")
+            .Case("0xc0f", "cortex-a15")
+            .Case("0xc20", "cortex-m0")
+            .Case("0xc23", "cortex-m3")
+            .Case("0xc24", "cortex-m4")
+            .Default("generic");
+
+  if (Implementer == "0x51") // Qualcomm Technologies, Inc.
+    // Look for the CPU part line.
+    for (unsigned I = 0, E = Lines.size(); I != E; ++I)
+      if (Lines[I].startswith("CPU part"))
+        // The CPU part is a 3 digit hexadecimal number with a 0x prefix. The
+        // values correspond to the "Part number" in the CP15/c0 register. The
+        // contents are specified in the various processor manuals.
+        return StringSwitch<const char *>(Lines[I].substr(8).ltrim("\t :"))
+            .Case("0x06f", "krait") // APQ8064
+            .Default("generic");
+
+  return "generic";
+}
+
+StringRef sys::LinuxReadCpuInfo::getHostCPUName_s390x(
+    const StringRef &ProcCpuinfoContent) {
+  // STIDP is a privileged operation, so use /proc/cpuinfo instead.
+
+  // The "processor 0:" line comes after a fair amount of other information,
+  // including a cache breakdown, but this should be plenty.
+  SmallVector<StringRef, 32> Lines;
+  ProcCpuinfoContent.split(Lines, "\n");
+
+  // Look for the CPU features.
+  SmallVector<StringRef, 32> CPUFeatures;
+  for (unsigned I = 0, E = Lines.size(); I != E; ++I)
+    if (Lines[I].startswith("features")) {
+      size_t Pos = Lines[I].find(":");
+      if (Pos != StringRef::npos) {
+        Lines[I].drop_front(Pos + 1).split(CPUFeatures, ' ');
+        break;
+      }
+    }
+
+  // We need to check for the presence of vector support independently of
+  // the machine type, since we may only use the vector register set when
+  // supported by the kernel (and hypervisor).
+  bool HaveVectorSupport = false;
+  for (unsigned I = 0, E = CPUFeatures.size(); I != E; ++I) {
+    if (CPUFeatures[I] == "vx")
+      HaveVectorSupport = true;
+  }
+
+  // Now check the processor machine type.
+  for (unsigned I = 0, E = Lines.size(); I != E; ++I) {
+    if (Lines[I].startswith("processor ")) {
+      size_t Pos = Lines[I].find("machine = ");
+      if (Pos != StringRef::npos) {
+        Pos += sizeof("machine = ") - 1;
+        unsigned int Id;
+        if (!Lines[I].drop_front(Pos).getAsInteger(10, Id)) {
+          if (Id >= 2964 && HaveVectorSupport)
+            return "z13";
+          if (Id >= 2827)
+            return "zEC12";
+          if (Id >= 2817)
+            return "z196";
+        }
+      }
+      break;
+    }
+  }
+
+  return "generic";
 }
-#endif
 
 #if defined(__i386__) || defined(_M_IX86) || \
     defined(__x86_64__) || defined(_M_X64)
 
 enum VendorSignatures {
   SIG_INTEL = 0x756e6547 /* Genu */,
   SIG_AMD = 0x68747541 /* Auth */
 };
case CPU_SUBTYPE_POWERPC_970:
     return "970";
   default:;
   }
 
   return "generic";
 }
 #elif defined(__linux__) && (defined(__ppc__) || defined(__powerpc__))
 StringRef sys::getHostCPUName() {
-  // Access to the Processor Version Register (PVR) on PowerPC is privileged,
-  // and so we must use an operating-system interface to determine the current
-  // processor type. On Linux, this is exposed through the /proc/cpuinfo file.
-  const char *generic = "generic";
-
-  // The cpu line is second (after the 'processor: 0' line), so if this
-  // buffer is too small then something has changed (or is wrong).
-  char buffer[1024];
-  ssize_t CPUInfoSize = readCpuInfo(buffer, sizeof(buffer));
-  if (CPUInfoSize == -1)
-    return generic;
-
-  const char *CPUInfoStart = buffer;
-  const char *CPUInfoEnd = buffer + CPUInfoSize;
-
-  const char *CIP = CPUInfoStart;
-
-  const char *CPUStart = 0;
-  size_t CPULen = 0;
-
-  // We need to find the first line which starts with cpu, spaces, and a colon.
-  // After the colon, there may be some additional spaces and then the cpu type.
-  while (CIP < CPUInfoEnd && CPUStart == 0) {
-    if (CIP < CPUInfoEnd && *CIP == '\n')
-      ++CIP;
-
-    if (CIP < CPUInfoEnd && *CIP == 'c') {
-      ++CIP;
-      if (CIP < CPUInfoEnd && *CIP == 'p') {
-        ++CIP;
-        if (CIP < CPUInfoEnd && *CIP == 'u') {
-          ++CIP;
-          while (CIP < CPUInfoEnd && (*CIP == ' ' || *CIP == '\t'))
-            ++CIP;
-
-          if (CIP < CPUInfoEnd && *CIP == ':') {
-            ++CIP;
-            while (CIP < CPUInfoEnd && (*CIP == ' ' || *CIP == '\t'))
-              ++CIP;
-
-            if (CIP < CPUInfoEnd) {
-              CPUStart = CIP;
-              while (CIP < CPUInfoEnd && (*CIP != ' ' && *CIP != '\t' &&
-                                          *CIP != ',' && *CIP != '\n'))
-                ++CIP;
-              CPULen = CIP - CPUStart;
-            }
-          }
-        }
-      }
-    }
-
-    if (CPUStart == 0)
-      while (CIP < CPUInfoEnd && *CIP != '\n')
-        ++CIP;
-  }
-
-  if (CPUStart == 0)
-    return generic;
-
-  return StringSwitch<const char *>(StringRef(CPUStart, CPULen))
-      .Case("604e", "604e")
-      .Case("604", "604")
-      .Case("7400", "7400")
-      .Case("7410", "7400")
-      .Case("7447", "7400")
-      .Case("7455", "7450")
-      .Case("G4", "g4")
-      .Case("POWER4", "970")
-      .Case("PPC970FX", "970")
-      .Case("PPC970MP", "970")
-      .Case("G5", "g5")
-      .Case("POWER5", "g5")
-      .Case("A2", "a2")
-      .Case("POWER6", "pwr6")
-      .Case("POWER7", "pwr7")
-      .Case("POWER8", "pwr8")
-      .Case("POWER8E", "pwr8")
-      .Case("POWER8NVL", "pwr8")
-      .Case("POWER9", "pwr9")
-      .Default(generic);
+  std::unique_ptr<llvm::MemoryBuffer> P = getProcCpuinfoContent();
+  const StringRef& Content = P ? P->getBuffer() : "";
+  return LinuxReadCpuInfo::getHostCPUName_powerpc(Content);
 }
 #elif defined(__linux__) && defined(__arm__)
 StringRef sys::getHostCPUName() {
-  // The cpuid register on arm is not accessible from user space. On Linux,
-  // it is exposed through the /proc/cpuinfo file.
-
-  // Read 1024 bytes from /proc/cpuinfo, which should contain the CPU part line
-  // in all cases.
-  char buffer[1024];
-  ssize_t CPUInfoSize = readCpuInfo(buffer, sizeof(buffer));
-  if (CPUInfoSize == -1)
-    return "generic";
-
-  StringRef Str(buffer, CPUInfoSize);
-
-  SmallVector<StringRef, 32> Lines;
-  Str.split(Lines, "\n");
-
-  // Look for the CPU implementer line.
-  StringRef Implementer;
-  for (unsigned I = 0, E = Lines.size(); I != E; ++I)
-    if (Lines[I].startswith("CPU implementer"))
-      Implementer = Lines[I].substr(15).ltrim("\t :");
-
-  if (Implementer == "0x41") // ARM Ltd.
-    // Look for the CPU part line.
-    for (unsigned I = 0, E = Lines.size(); I != E; ++I)
-      if (Lines[I].startswith("CPU part"))
-        // The CPU part is a 3 digit hexadecimal number with a 0x prefix. The
-        // values correspond to the "Part number" in the CP15/c0 register. The
-        // contents are specified in the various processor manuals.
-        return StringSwitch<const char *>(Lines[I].substr(8).ltrim("\t :"))
-            .Case("0x926", "arm926ej-s")
-            .Case("0xb02", "mpcore")
-            .Case("0xb36", "arm1136j-s")
-            .Case("0xb56", "arm1156t2-s")
-            .Case("0xb76", "arm1176jz-s")
-            .Case("0xc08", "cortex-a8")
-            .Case("0xc09", "cortex-a9")
-            .Case("0xc0f", "cortex-a15")
-            .Case("0xc20", "cortex-m0")
-            .Case("0xc23", "cortex-m3")
-            .Case("0xc24", "cortex-m4")
-            .Default("generic");
-
-  if (Implementer == "0x51") // Qualcomm Technologies, Inc.
-    // Look for the CPU part line.
-    for (unsigned I = 0, E = Lines.size(); I != E; ++I)
-      if (Lines[I].startswith("CPU part"))
-        // The CPU part is a 3 digit hexadecimal number with a 0x prefix. The
-        // values correspond to the "Part number" in the CP15/c0 register. The
-        // contents are specified in the various processor manuals.
-        return StringSwitch<const char *>(Lines[I].substr(8).ltrim("\t :"))
-            .Case("0x06f", "krait") // APQ8064
-            .Default("generic");
-
-  return "generic";
+  std::unique_ptr<llvm::MemoryBuffer> P = getProcCpuinfoContent();
+  const StringRef& Content = P ? P->getBuffer() : "";
+  return LinuxReadCpuInfo::getHostCPUName_arm(Content);
 }
 #elif defined(__linux__) && defined(__s390x__)
 StringRef sys::getHostCPUName() {
-  // STIDP is a privileged operation, so use /proc/cpuinfo instead.
-
-  // The "processor 0:" line comes after a fair amount of other information,
-  // including a cache breakdown, but this should be plenty.
-  char buffer[2048];
-  ssize_t CPUInfoSize = readCpuInfo(buffer, sizeof(buffer));
-  if (CPUInfoSize == -1)
-    return "generic";
-
-  StringRef Str(buffer, CPUInfoSize);
-  SmallVector<StringRef, 32> Lines;
-  Str.split(Lines, "\n");
-
-  // Look for the CPU features.
-  SmallVector<StringRef, 32> CPUFeatures;
-  for (unsigned I = 0, E = Lines.size(); I != E; ++I)
-    if (Lines[I].startswith("features")) {
-      size_t Pos = Lines[I].find(":");
-      if (Pos != StringRef::npos) {
-        Lines[I].drop_front(Pos + 1).split(CPUFeatures, ' ');
-        break;
-      }
-    }
-
-  // We need to check for the presence of vector support independently of
-  // the machine type, since we may only use the vector register set when
-  // supported by the kernel (and hypervisor).
-  bool HaveVectorSupport = false;
-  for (unsigned I = 0, E = CPUFeatures.size(); I != E; ++I) {
-    if (CPUFeatures[I] == "vx")
-      HaveVectorSupport = true;
-  }
-
-  // Now check the processor machine type.
-  for (unsigned I = 0, E = Lines.size(); I != E; ++I) {
-    if (Lines[I].startswith("processor ")) {
-      size_t Pos = Lines[I].find("machine = ");
-      if (Pos != StringRef::npos) {
-        Pos += sizeof("machine = ") - 1;
-        unsigned int Id;
-        if (!Lines[I].drop_front(Pos).getAsInteger(10, Id)) {
-          if (Id >= 2964 && HaveVectorSupport)
-            return "z13";
-          if (Id >= 2827)
-            return "zEC12";
-          if (Id >= 2817)
-            return "z196";
-        }
-      }
-      break;
-    }
-  }
-
-  return "generic";
+  std::unique_ptr<llvm::MemoryBuffer> P = getProcCpuinfoContent();
+  const StringRef& Content = P ? P->getBuffer() : "";
+  return LinuxReadCpuInfo::getHostCPUName_s390x(Content);
 }
 #else
 StringRef sys::getHostCPUName() { return "generic"; }
 #endif
 
 #if defined(__linux__) && defined(__x86_64__)
 // On Linux, the number of physical cores can be computed from /proc/cpuinfo,
 // using the number of unique physical/core id pairs. The following
bool sys::getHostCPUFeatures(StringMap<bool> &Features) {
   Features["xsaveopt"] = HasAVXSave && HasLeafD && ((EAX >> 0) & 1);
   Features["xsavec"] = HasAVXSave && HasLeafD && ((EAX >> 1) & 1);
   Features["xsaves"] = HasAVXSave && HasLeafD && ((EAX >> 3) & 1);
 
   return true;
 }
 #elif defined(__linux__) && (defined(__arm__) || defined(__aarch64__))
 bool sys::getHostCPUFeatures(StringMap<bool> &Features) {
-  // Read 1024 bytes from /proc/cpuinfo, which should contain the Features line
-  // in all cases.
-  char buffer[1024];
-  ssize_t CPUInfoSize = readCpuInfo(buffer, sizeof(buffer));
-  if (CPUInfoSize == -1)
+  std::unique_ptr<llvm::MemoryBuffer> P = getProcCpuinfoContent();
+  if (!P)
     return false;
 
-  StringRef Str(buffer, CPUInfoSize);
-
   SmallVector<StringRef, 32> Lines;
-  Str.split(Lines, "\n");
+  P->getBuffer().split(Lines, "\n");
 
   SmallVector<StringRef, 32> CPUFeatures;
 
   // Look for the CPU features.
   for (unsigned I = 0, E = Lines.size(); I != E; ++I)
     if (Lines[I].startswith("Features")) {
       Lines[I].split(CPUFeatures, ' ');
       break;

llvm/trunk/unittests/Support/Host.cpp

 TEST_F(HostTest, NumPhysicalCores) {
   int Num = sys::getHostNumPhysicalCores();
 
   if (isSupportedArchAndOS())
     ASSERT_GT(Num, 0);
   else
     ASSERT_EQ(Num, -1);
 }
+
+TEST(getLinuxHostCPUName, ARM) {
+  StringRef CortexA9ProcCpuinfo = R"(
+processor       : 0
+model name      : ARMv7 Processor rev 10 (v7l)
+BogoMIPS        : 1393.66
+Features        : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32
+CPU implementer : 0x41
+CPU architecture: 7
+CPU variant     : 0x2
+CPU part        : 0xc09
+CPU revision    : 10
+
+processor       : 1
+model name      : ARMv7 Processor rev 10 (v7l)
+BogoMIPS        : 1393.66
+Features        : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32
+CPU implementer : 0x41
+CPU architecture: 7
+CPU variant     : 0x2
+CPU part        : 0xc09
+CPU revision    : 10
+
+Hardware        : Generic OMAP4 (Flattened Device Tree)
+Revision        : 0000
+Serial          : 0000000000000000
+)";
+
+  EXPECT_EQ(sys::LinuxReadCpuInfo::getHostCPUName_arm(CortexA9ProcCpuinfo),
+            "cortex-a9");
+  EXPECT_EQ(
+      sys::LinuxReadCpuInfo::getHostCPUName_arm("CPU implementer : 0x41\n"
+                                                "CPU part        : 0xc0f"),
+      "cortex-a15");
+  // Verify that both CPU implementer and CPU part are checked:
+  EXPECT_EQ(
+      sys::LinuxReadCpuInfo::getHostCPUName_arm("CPU implementer : 0x40\n"
+                                                "CPU part        : 0xc0f"),
+      "generic");
+  EXPECT_EQ(
+      sys::LinuxReadCpuInfo::getHostCPUName_arm("CPU implementer : 0x51\n"
+                                                "CPU part        : 0x06f"),
+      "krait");
+}