There are two kinds of stats in the system. The old one requires an
unique name, while the new one requires an local name. The setName
function has a flag to specify the difference. In the constructor of
InfoAccess, it sets correct flag to the setName function. However, if
you set the name later with the setter, it wouldn't set the flag for
you. This leads the name conflict in new style stats with same local
name. We should also pass the correct flag in the name setter.
Change-Id: I0fcaad3cca65d0f2859c5f6cb28a00813a026a0c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52323
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The GPU models support a simple register allocation policy (1 WF/CU at a
time) and a dynamic register allocation policy (up to max WF/CU at a
time). By default, the simple policy is used. However, the dynamic
policy is much more realistic relative to real hardware and thus much
more important to ensure it works in the regressions. This commit
updates the nightly and weekly regressions accordingly to run the
dynamic register allocation policy.
Change-Id: Id263d3d5e19e4ff47f0eb6d9b08cbafdf2177fb9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52163
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Add the Pannotia benchmarks to the weekly regression suite. These
applications do a good job of testing the GPU support for irregular
access patterns of various kinds. All inputs have been sized to use
relatively small graphs to avoid increasing runtime too much. However,
even with small input sizes Pannotia does run for a while.
Note that the Pannotia benchmarks also use m5ops in them. Thus, this
commit also adds support into the weekly regression for compiling the
m5ops (for x86, since that is what the GPU model assumes for the CPU).
Change-Id: I1f68b02b38ff24505a2894694b7544977024f8fa
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51968
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
This was conditioned on the TARGET_ISA being x86 because the code it
replaced was, and that was because the x86 interrupts object had an
extra port that didn't appear for other ISAs. This inconsistency is not
present on either side of this connection, and so we don't need it to be
conditional.
We do, however, need to ensure that the port sends a range change even
if it doesn't have any ranges to send, to satisfy the bookkeeping of the
bus on the other side of the connection. We do that in init, like leaf
devices do.
Change-Id: Idec6f6c5e2cf78b113fb238d0edd2c63d6cd2c23
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52109
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The only difference between the RiscvUart8250 and the regular Uart8250
is that the Riscv version knows how to generate a device tree node
appropriate for use in a Riscv system. This lets us drop the TARGET_ISA
check from that method, since that should be called iff the target
system is Riscv.
Also update the HiFive platform to use the RiscvUart8250 so that it can
continue to generate device trees successfully.
Change-Id: I306596efffed5e5eed337d3db492d2782ebfaa8d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52144
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This change adds GUPSGenCore, GUPSGen, GUPSGenEP, and GUPSGenPAR.
GUPSGenCore inherits from AbstractGeneratorCore. It is used for
implementing GUPSGen, GUPSGenEP, and GUPSGenPAR which inherit from
AbstractProcessor. GUPSGen does not implement a multi-core
generator as there are two ways to implement GUPS in parallel.
GUPSGenEP implement GUPS in it Embarrassingly Parallel variant
where multiple instances of GUPS update separate partitions of the
memory. GUPSGenPAR impelements GUPS in its Parallel variant where
multiple generators acccess the same partition of the memory in
parallel.
Change-Id: I57fb327a1ddefb6735ee59a0d7b4609e50af3517
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51613
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
This change adds the source code for the PortTerminator SimObject.
It could be used to connect request/response ports in the system
that can not be connected to any other ports. This will prevent
errors caused by orphan ports in the system. As an example if
you have set up a cache hierarchy and do not want to test its
performance in full system mode and want to use PyTrafficGen
instead, your system will end up with an icache or walker ports
that are not connected to anything. In this case, you can use a
PortTerminator to connect the orphan ports in your system.
Change-Id: I5e19cdd3ce064638ffabf29d29225eda77ffc146
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51609
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
This simplifies the O3 CPU, and removes special cases around how vector
registers are handled. Now ARM is responsible for maintaining its
different register personalities internally.
Also, this re-establishes the invariant that registers are indexed as
complete, opaque entities with no internal structure, at least as far as
the CPU is concerned.
To make sure the KVM CPU sees the correct state, we need to sync over
the vector registers if we're in 32 bit mode when moving state to or
from gem5's ThreadContext.
Change-Id: I36416d609310ae0bc50c18809f5d9e19bfbb4d37
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49147
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Some aspects of the formatting in this file were questionable, like
aligning =s between adjacent lines, although not technically against the
style rules as far as I know.
More strangely though, the whole file used three space indents instead
of the typical four.
Change-Id: I7b60f1978c5b2c60a15296b10d09d5701cf7fa5c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52108
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These are called from the ThreadContext, and should not be counted in
the statistics. The (read|set)*Reg methods, aka readIntReg and not
readArchIntReg, are called from the (read|set)*RegOperand methods in the
DynInst, which is the ExecContext implementation when running on O3.
Change-Id: I9abf90fc7bbe80a742325b6dfd3c0e14392af54c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51428
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
The x86 KVM CPU had been in the cpu/kvm directory, while the arm CPU was
inconsistently in the arch/arm directory.
This change moves the x86 CPU to be in arch/x86, restoring consistency.
This location will make the KVM support more modular, by not having the
x86 CPU implementation right alongside the generic implementation.
Change-Id: Ia13151f843df8f8877bfef5ff620825877d3dffa
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52085
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This virtual method can trivially be shared among different CPUs, making
it unnecessary to cast from a BaseCPU pointer to some more specific CPU
class. The existing similar functions which implement this functionality
are only trivially different, and can be merged into overloads of this
common method.
Noteably this method is not implemented for the MinorCPU which uses the
SimpleThread class, typedef-ed to be MinorThread. If the previous
version of this method had been called on that CPU, it would have
crashed the simulator since a dynamic_cast would have failed. This
doesn't provide an implementation for the MinorCPU, but it also doesn't
make the problem worse, and provides a way to actually implement it some
day.
Change-Id: I23399ea6bbbbabd87e6c8bf7a66d48902745d2cf
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52084
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Currently MOESI_AMD_Base used in VIPER has a CPUonly parameter which
indicates that messages should not try to add GPU SLICC controllers as
destinations. This adds the analogue GPUonly parameter which indicates
that requests should not try to add CPU SLICC controllers.
Also adds an assert to ensure the outgoing message has at least one
destination. This assert would indicate a misconfiguration.
Change-Id: Ibb0affd4606084fca021f0e7c117d4ff8c06d429
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51928
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
The CPUonly variable in MOESI_AMD_Base's Directory indicates that probes
should not be sent to any GPU SLICC controllers as they are not part of
CPU. There is one CPUonly check missing which causes problems in
GPU-only Ruby networks as there is no route to any controllers with that
MachineType. Add a condition to check CPUonly and do nothing in that
case.
Change-Id: I41b6c04feec473e34b04402adfb5978e75b847b6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51927
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
SCons does not use a variable called LDFLAGS, it uses one called
LINKFLAGS. Switch some errant uses to the correct name.
Also, adjust all the other variable names to use LINK, for consistency
and to avoid confusion and avoid mistakes in the future.
Change-Id: I38d40f5231afdf62bcfba04478d403d65e9b1e26
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51987
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This translation generator is returned by the new version of the
TranslateFunctional method which translates a region rather than a
single address. That method is currently virtual with a default
implementation which is not overloaded, but the plan is for the other
MMUs to override that method and inject their own page size minimally.
In the future, the MMUTranslationGen class and the implementations in
the MMUs may be updated so that they can, for instance, handle varying
page sizes across a single translation.
Change-Id: I39479f0f0e8150fc6e3e1a7097a0c8bd8d22d4e0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50759
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
66a056b8 changed the weekly regression to use a single docker for
all GPU tests, to reduce how many times gem5 needed to be compiled.
However, in my local testing of that patch, gem5-resources was not
deleted until after the docker was created -- which causes a problem
when gem5-resources does not exist already from a prior run, since
the creation of the dockerfile requires it for HACC. This commit
fixes this problem by moving the pull of gem5-resources to be before
anything else related to the GPU happens.
Change-Id: I006860204d03807d95628aa5dcf6e82d202fef9c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51907
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
This tests forking gem5 and simulating the child with a different cpu.
The test boots linux with the KVM cpu and then forks gem5. Each child
simulation switches to the specified cpu and simulates to completion
while the parents waits for the children to finish before also
simulating to completion.
Change-Id: I68d7515bf125c855eefc62ba4798cd7c745ef2b0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50467
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
The arch implies gem5 lib, and not the other way around. Or in other
words, if, for example, x86 is the ISA, the having the tag 'x86 isa'
would imply that that file also has the tag 'gem5 lib'. Having the tag
'gem5 lib' would not imply 'x86 isa'.
This worked out because when testing for a single tag, we were using
with_any_tags, and 'gem5 lib' would expand to 'gem5 lib' and 'x86 isa'.
Then we would match files which were non-specific and used 'gem5 lib',
or files which had more specifically used 'x86 isa' only. Files which
used, for instance, 'arm isa', would not meet either criteria of the
implied "or".
Change-Id: I301d1bbbbcac1594371584d4b0d5d291b7b77fc4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51827
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Daniel Carvalho <odanrc@yahoo.com.br>
The tags for source files need to be resolved as well as the tags for
the filters themselves.
For example, the 'x86 isa' tag could imply 'gem5 lib'. If we filter for
all files which include the tag 'gem5 lib', we would also want to get
all the files that used the tag 'x86 isa' by itself, since that would
imply 'gem5 lib' as well.
Change-Id: Ie513778cc5b8ac1f1893728b14e84cabdaabf0e6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51828
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
In order to have more fine grained control over which SLICC controllers
are part of which Ruby network in a disjoint configuration, the
create_system function in GPU_VIPER is broken up into multiple construct
calls for each SLICC machine type in the protocol. By default this does
not change anything functionally. A future config will use the construct
calls to explicitly set which network (CPU or GPU) the controller is in.
Change-Id: Ic038b300c5c3732e96992ef4bfe14e43fa0ea824
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51847
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
