Is it guaranteed that all Denver CPUs will have coherent caches? I'd like to
make sure that this code is still correct when Denver 5 comes out and
everyone
forgot that this code is avoiding I$ fushes.
https://codereview.chromium.org/797233002/diff/1/src/arm64/assembler-arm64.cc
File src/arm64/assembler-arm64.cc (right):
https://codereview.chromium.org/797233002/diff/1/src/arm64/assembler-arm64.cc#newcode48
src/arm64/assembler-arm64.cc:48: supported_ = 0;
The ARM and x64 version of this file also have:
// Only use statically determined features for cross compile
(snapshot).
if (cross_compile) return;
Shoud this fie also do this?
https://codereview.chromium.org/797233002/diff/1/src/base/cpu.cc
File src/base/cpu.cc (right):
https://codereview.chromium.org/797233002/diff/1/src/base/cpu.cc#newcode344
src/base/cpu.cc:344:
You can call CPUID again with 1 in EAX and get the Model and Extended
Model fields, which are similar to the variant field from cpuinfo.
https://codereview.chromium.org/797233002/diff/1/src/base/cpu.cc#newcode405
src/base/cpu.cc:405: variant_ = 0;
The failure value here is 0, and as Benedikt pointed out above he'd like
the default to be 0.
Won't 0 be the same value as the "Denver" variant? It sounds like
/proc/cpuinfo identifies Denver as variant 0? What do other Tegra
devices return as variant?
https://codereview.chromium.org/797233002/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
