Refactors CPU feature detection.

Refactors some CPU feature detection into new class CpuInfo, and uses new information in VM service.

This change rewrites the code from the ARM assembler for parsing /proc/cpuinfo on Linux and Android, and collects it into a CpuInfo class that can be used for other architectures as well. This code is in cpuinfo_*.cc. /proc/cpuinfo equivalents are used for Mac and Windows. CpuInfo is used by the VM service to report on the hardware dart is running on. In the future CpuInfo can also be used here to provide more information.

R=iposva@google.com, johnmccutchan@google.com

Committed: https://code.google.com/p/dart/source/detail?r=32468

[Cutch, 2014-01-02 19:39:18]

https://codereview.chromium.org/120723003/diff/1190001/runtime/vm/cpu_ia32.h
File runtime/vm/cpu_ia32.h (right):

https://codereview.chromium.org/120723003/diff/1190001/runtime/vm/cpu_ia32.h#...
runtime/vm/cpu_ia32.h:22: static const uint64_t kSSE2BitMask =
static_cast<uint64_t>(1) << 26;
Should this be here or inside the .cc file?

https://codereview.chromium.org/120723003/diff/1190001/runtime/vm/cpu_ia32.h#...
runtime/vm/cpu_ia32.h:28: #define HARDWARE_LEN 64
This #define and hardware_ is repeated in all files, can it be factored into a
base class?

https://codereview.chromium.org/120723003/diff/1190001/runtime/vm/cpuinfo.h
File runtime/vm/cpuinfo.h (right):

https://codereview.chromium.org/120723003/diff/1190001/runtime/vm/cpuinfo.h#n...
runtime/vm/cpuinfo.h:16: static void Read();
Rename to InitOnce ?

https://codereview.chromium.org/120723003/diff/1190001/runtime/vm/cpuinfo_and...
File runtime/vm/cpuinfo_android.cc (right):

https://codereview.chromium.org/120723003/diff/1190001/runtime/vm/cpuinfo_and...
runtime/vm/cpuinfo_android.cc:112: const char* field, char* dest, const intptr_t
dest_len) {
Should the OS specific code populate a field table and then ExtractField,
HasField just queries the table?

https://codereview.chromium.org/120723003/diff/1190001/runtime/vm/service.cc
File runtime/vm/service.cc (right):

https://codereview.chromium.org/120723003/diff/1190001/runtime/vm/service.cc#...
runtime/vm/service.cc:520: jsobj.AddProperty("built-for", CPU::Id());
please use "fooBar" or "foo_bar" for property names.

[zra, 2014-01-13 21:57:18]

PTAL

Reorganized following discussion with Ivan. Aside from the reorg, this also uses
__cpuid on windows for detecting the presence of sse2 and sse4.1 so that we
don't have to run generated code during VM initialization to detect CPU
properties.

https://codereview.chromium.org/120723003/diff/1190001/runtime/vm/service.cc
File runtime/vm/service.cc (right):

https://codereview.chromium.org/120723003/diff/1190001/runtime/vm/service.cc#...
runtime/vm/service.cc:520: jsobj.AddProperty("built-for", CPU::Id());
On 2014/01/02 19:39:19, Cutch wrote:
> please use "fooBar" or "foo_bar" for property names.

Done.

[Cutch, 2014-01-15 20:50:48]

https://codereview.chromium.org/120723003/diff/1700001/runtime/vm/cpuinfo_mac...
File runtime/vm/cpuinfo_macos.cc (right):

https://codereview.chromium.org/120723003/diff/1700001/runtime/vm/cpuinfo_mac...
runtime/vm/cpuinfo_macos.cc:69: "machdep.cpu.brand_string",
Wouldn't it be better if the field names were abstracted? That way the calling
code doesn't have to care about which OS it's running on.

[Cutch, 2014-01-15 21:30:48]

lgtm

[Ivan Posva, 2014-01-21 21:41:02]

https://codereview.chromium.org/120723003/diff/1700001/runtime/vm/cpu_mips.h
File runtime/vm/cpu_mips.h (right):

https://codereview.chromium.org/120723003/diff/1700001/runtime/vm/cpu_mips.h#...
runtime/vm/cpu_mips.h:12: class HostCPUFeatures: public AllStatic {
Don't you support the same simulator overriding capability here? Maybe add the
same comment as in ARM.

https://codereview.chromium.org/120723003/diff/1700001/runtime/vm/cpuinfo_mac...
File runtime/vm/cpuinfo_macos.cc (right):

https://codereview.chromium.org/120723003/diff/1700001/runtime/vm/cpuinfo_mac...
runtime/vm/cpuinfo_macos.cc:67: const char *CpuInfo::fields_[] = {
How about adding index values for these fields?

[zra, 2014-01-24 21:18:27]

https://codereview.chromium.org/120723003/diff/1700001/runtime/vm/cpu_mips.h
File runtime/vm/cpu_mips.h (right):

https://codereview.chromium.org/120723003/diff/1700001/runtime/vm/cpu_mips.h#...
runtime/vm/cpu_mips.h:12: class HostCPUFeatures: public AllStatic {
On 2014/01/21 21:41:02, Ivan Posva wrote:
> Don't you support the same simulator overriding capability here? Maybe add the
> same comment as in ARM.

Done.

https://codereview.chromium.org/120723003/diff/1700001/runtime/vm/cpuinfo_mac...
File runtime/vm/cpuinfo_macos.cc (right):

https://codereview.chromium.org/120723003/diff/1700001/runtime/vm/cpuinfo_mac...
runtime/vm/cpuinfo_macos.cc:67: const char *CpuInfo::fields_[] = {
On 2014/01/21 21:41:02, Ivan Posva wrote:
> How about adding index values for these fields?

Unfortunately, there are no designated initializers in C++, but what I've done
is written a function called from InitOnce to fill in the fields_ array using
the index value enums.

https://codereview.chromium.org/120723003/diff/1700001/runtime/vm/cpuinfo_mac...
runtime/vm/cpuinfo_macos.cc:69: "machdep.cpu.brand_string",
On 2014/01/15 20:50:49, Cutch wrote:
> Wouldn't it be better if the field names were abstracted? That way the calling
> code doesn't have to care about which OS it's running on.

There is an abstracted interface through the enum in the header file. I wanted
to also expose the string-based interface for development/experimentation before
adding new fields to the enum.

[Ivan Posva, 2014-02-06 00:41:54]

LGTM -ip

[zra, 2014-02-08 22:27:41]

Committed patchset #19 manually as r32468 (presubmit successful).

[siva, 2014-02-11 01:13:22]

https://codereview.chromium.org/120723003/diff/2240001/runtime/vm/cpuinfo_lin...
File runtime/vm/cpuinfo_linux.cc (right):

https://codereview.chromium.org/120723003/diff/2240001/runtime/vm/cpuinfo_lin...
runtime/vm/cpuinfo_linux.cc:42: fp = fopen(PATHNAME, "r");
We need to rethink this CL.

The renderer process in chrome is not going to allow reading of files like this.


The current assertion that we are hitting in Dartium with debug builds is
because the fields are not initialized and HasField returns false resulting in
the assertion
HasField(FieldName(kCpuInfoModel)) being triggered.

[zra, 2014-02-11 02:57:47]

https://codereview.chromium.org/120723003/diff/2240001/runtime/vm/cpuinfo_lin...
File runtime/vm/cpuinfo_linux.cc (right):

https://codereview.chromium.org/120723003/diff/2240001/runtime/vm/cpuinfo_lin...
runtime/vm/cpuinfo_linux.cc:42: fp = fopen(PATHNAME, "r");
We can revert ia32 and x64 to assemble and run the cpuinfo instruction, but the
analogous instruction is privileged on ARM and MIPS, so reading /proc/cpuinfo is
the only way on Linux and Android to find out what CPU we're running on. Is
there some other way to read files in Dartium?

On 2014/02/11 01:13:22, siva wrote:
> We need to rethink this CL.
> 
> The renderer process in chrome is not going to allow reading of files like
this.
> 
> 
> The current assertion that we are hitting in Dartium with debug builds is
> because the fields are not initialized and HasField returns false resulting in
> the assertion
> HasField(FieldName(kCpuInfoModel)) being triggered.