Global instructions are new in Vega and are essentially FLAT
instructions from GCN3 but guaranteed to go to global memory where as
flat can go to global or local memory.
This reworks the flat instruction classes so that the initiateAcc /
execute / completeAcc logic can be reused for flat, global, and later
scratch subtypes of flat instructions. The decoder creates a flat
instruction class which sets instruction flags based on the flat
instruction's SEG field. There are new initOperandInfo and
generateDissasmbly methods for flat and global. The number of operands
and operand index getters are modified to check the flags and return the
correct value for the subtype.
Change-Id: I1db4a3742aeec62424189e54c38c59d6b1a8d3c1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/47106
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Kyle Roarty <kyleroarty1716@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The Executable class was used both for the generic gem5 target, and as a
base for the GTest binaries, the systemc test binaries, etc.
Unfortunately, the gem5 binary needs to include src/base/date.cc, and to
ensure that that file is up to date, it needs to depend on all the other
object files. No other binary should have that, but it was included by
inheritance.
Also, depending on the object file works well when those object files
and the date.cc object file are all part of the same binary and not
mixed and matched. That is not true for the GTest binaries for instance,
and so building a unit test would also build all the other unit test
object files because they are dependencies for date.to, date.tdo, etc.
If they already exist, then they would satisfy the dependency and not be
rebuilt.
Change-Id: Ia9cdddc5b2593678e714c08655eb440d7f5b5d1f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51088
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
This is removing the cached boolean variables from the ISA class.
The ISA is now using a release object.
It is importing it from the ArmSystem in case of a FS simulation,
and it is using its own ArmRelease object in SE mode
This allows us to add/remove SE extensions from python, rather than
hardcoding them in the ISA constructor (in case of SE)
Change-Id: I2b0b2f113e7bb9e28ac86bf2139413e2a71eeb01
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51012
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
The constructor of the LoadQueue and StoreQueue were adding
an additional entry compared to the given configuration.
The removed comment was saying that this additional entry was
used as a dummy entry.
This is not necessary anymore with the current structure.
It was even leading to incorrect behavior as a loadQueue
could have one more outstanding load than specified
by the configuration.
Valgrind does not spot any illegal access.
Change-Id: I41507d003e4d55e91215e21f57119af7b3e4d465
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50732
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
This parameter is used to figure out if two addresses are on the same or
different pages, and could be used to find what page they were on and
the page offset, although it doesn't look like the later two are
actually used.
This value could possibly come from the TLB parameter attached to the
prefetcher, but making it explicit makes these more symmetric with the
Ruby prefetcher, and reduces the complexity of the TLB implementation.
Change-Id: I6921943c49af19971b84225ecfd1127304363426
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50352
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
This made it skip over 70 pages to be "what it was before" my page table
changes. I'm not sure what changes this is referring to, and the class
which manages page tables in the guest memory uses the allocPhysPages
method to allocate its memory and would cooperate with anything else
using this mechanism without having to have special accomodation.
I removed this hack and hello world seems to work fine, but there may be
some other test case which exposes some problems.
Change-Id: I16e0d8835452df9c3e79738a1eed05b4cc9372b7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50349
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
LULESH is a popular GPU HPC application that acts as a good test
for several memory and compute patterns. Thus, including it in
the weekly regressions will help verify correctness and
functionality for code that affects the GPU. The default LULESH
input runs 10 iterations and takes 3-4 hours. Hence, it is not
appropriate for nightly regressions.
Change-Id: Ic1b73ab32fdd5cb1b973f2676b272adb91b2a98e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50952
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
HeteroSync does a good job of testing the GPU memory system and
atomics support, without requiring a long runtime. Thus, this
commit adds a mutex and barrier test from HeteroSync to the
nightly regression to ensure these components are tested.
Change-Id: I65998a0a63d41dd3ba165c3a000cee7e42e9034a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50951
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
In the MemPool object, the idea of a limit of the pool (largest page)
and the total number of pages were conflated, as was the page number of
the next "free" page and the total number of pages allocated. Both of
those would only be equivalent if the memory pool starts at address
zero, which is not generally true and could be true for at most one pool
at a time even when it is occasionally true.
Instead, this change fixes up MemPool to keep tree values, a starting
page number, the page number of the next free page, and the total number
of pages in the pool, both allocated and unallocated.
With those three values, we can accurately report the number of
allocated pages (not just the number of pages of any kind below the next
free one), the total number of free pages, and the total number of pages
in general (not the largest numbered page in the pool).
The value serialized by the System class was adjusted so that it will
stay compatible with previous checkpoints. The value unserialized by the
system class is passed to the MemPool as a limit, which has not changed
and so doesn't need to be updated. It gets translated into the total
number of pages in the MemPool constructor.
Change-Id: I8268ef410b41bf757df9ee5585ec2f6b0d8499e1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50687
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Turn the functions within it into virtual methods on the ISA classes.
Eliminate the implementation in MIPS, which was just copy pasted from
Alpha long ago. Fix some minor style issues in ARM. Remove templating.
Switch from using an "XC" type parameter to using the ThreadContext *
installed in all ISA classes.
The ARM version of these functions actually depend on the ExecContext
delaying writes to MiscRegs to work correctly. More insiduously than
that, they also depend on the conicidental ThreadContext like
availability of certain functions like contextId and getCpuPtr which
come from the class which happened to implement the type passed into XC.
To accomodate that, those functions need both a real ThreadContext, and
another object which is either an ExecContext or a ThreadContext
depending on how the method is called.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1053
Change-Id: I68f95f7283f831776ba76bc5481bfffd18211bc4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50087
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Similar to the flags issue in the previous patch, the FlatGlobal flag
does not exist. Change all of the flat instructions to use the same
issue logic as GCN3. A helper function is also added as loads and stores
use the same interface. The helper function can be more easily updated
to support global and scratch subtypes of flat instructions.
Change-Id: I394f1d4c59b029201fe2f6075c9dedb3a37dbe31
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50827
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Kyle Roarty <kyleroarty1716@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The instructions file seems to be assuming a newer pipeline which is not
released. The flags are therefore not set in Vega as the newer pipeline
infers them. This adds back flags for MemoryRef instructions, fixes
waitcnt and removes CondBranch which was not checked and changed to
Branch.
This also removeds unused Cac flags and fixes the casing for ReadsEXEC
and WritesEXEC. The remaining flags are not used at all by the pipeline
and are removed to avoid confusion as to whether these are needed for
GCN3 or not.
Change-Id: I976cbd407a466e8ad77c84dbdc29082f49e28f3b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/47102
Reviewed-by: Kyle Roarty <kyleroarty1716@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
