Those instructions were broken after:
https://gem5-review.googlesource.com/c/public/gem5/+/38381/4
Which is effectively replacing the generic StaticInst src and dest
reg array with an instruction specific one.
The size of the array is evaluated by the ISA parser, which is
counting the operands when parsing the isa code.
Alas, Compare and Swap Pair instructions were augmenting the number
of destination and source registers in the C++ world, which is
invisible to the parser. This lead to an out of bounds access
of the arrays.
This patch is fixing this behaviour by defining XResult2, which
is the second compare/result register for a paired CAS
Change-Id: Ie35c26256f42459805e007847896ac58b178fd42
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39456
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
As the std namespace expands, it becomes more and more likely that
blanketly importing all its symbols will cause a collision. Also, when
it was imported, the std:: was used or left off arbitrarily, sometimes
inconsistently even in the same function signature.
Change-Id: Ie30cbab154b00c60433908a206c229230d2b109f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39536
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
We currently use the traditional SI-like prefixes for to represent
binary multipliers in some contexts. This is ambiguous in many cases
since they overload the meaning of the SI prefix.
Here are some examples of commonly used in the industry:
* Storage vendors define 1 MB as 10**6 bytes
* Memory vendors define 1 MB as 2**20 bytes
* Network equipment treats 1Mbit/s as 10**6 bits/s
* Memory vendors define 1Mbit as 2**20 bits
In practice, this means that a FLASH chip on a storage bus uses
decimal prefixes, but that same flash chip on a memory bus uses binary
prefixes. It would also be reasonable to assume that the contents of a
1Mbit FLASH chip would take 0.1s to transfer over a 10Mbit Ethernet
link. That's however not the case due to different meanings of the
prefix.
The quantity 2MX is treated differently by gem5 depending on the unit
X:
* Physical quantities (s, Hz, V, A, J, K, C, F) use decimal prefixes.
* Interconnect and NoC bandwidths (B/s) use binary prefixes.
* Network bandwidths (bps) use decimal prefixes.
* Memory sizes and storage sizes (B) use binary prefixes.
Mitigate this ambiguity by consistently using the ISO/IEC/SI prefixes
for binary multipliers for parameters and comments where appropriate.
Change-Id: I2d24682d207830f3b7b0ad2ff82b55e082cccb32
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39576
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When running multithreaded programs in SE-mode with DerivO3CPU model,
there are cases that two or more cores have page faults on the same page
in nearby ticks (can be at the same tick) when fetching instructions
(more likely) or accessing data. When these cores try come to the commit
stage in nearby ticks/cycles, they will try to handle the faults
(without clobbering). Then the first core will ask for a physical page
frame to map with the virtual page. In the previous version, the right
next core that tries to handle the fault will hit a panic condition in
the EmulationPageTable::map(...) as the page has been mapped and this
page fault is not to clobber the existing mapping.
In this changeset, if it is found that the page has been mapped and it
is not to clobber the existing mapping, it will return without further
mapping activities as the page fault has been handled previously.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-798
Change-Id: I9bb1163f9d1379c6fed9725101e4400fefdc8079
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39515
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
We currently use the traditional SI-like prefixes for to represent
binary multipliers in some contexts. This is ambiguous in many cases
since they overload the meaning of the SI prefix.
Here are some examples of commonly used in the industry:
* Storage vendors define 1 MB as 10**6 bytes
* Memory vendors define 1 MB as 2**20 bytes
* Network equipment treats 1Mbit/s as 10**6 bits/s
* Memory vendors define 1Mbit as 2**20 bits
In practice, this means that a FLASH chip on a storage bus uses
decimal prefixes, but that same flash chip on a memory bus uses binary
prefixes. It would also be reasonable to assume that the contents of a
1Mbit FLASH chip would take 0.1s to transfer over a 10Mbit Ethernet
link. That's however not the case due to different meanings of the
prefix.
The quantity 2MX is treated differently by gem5 depending on the unit
X:
* Physical quantities (s, Hz, V, A, J, K, C, F) use decimal prefixes.
* Interconnect and NoC bandwidths (B/s) use binary prefixes.
* Network bandwidths (bps) use decimal prefixes.
* Memory sizes and storage sizes (B) use binary prefixes.
Mitigate this ambiguity by consistently using the ISO/IEC/SI prefixes
for binary multipliers for parameters and comments where appropriate.
Change-Id: I6ab03934af850494d95a37dcda5c2000794b4d3a
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39578
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The warning happens when a key is present in the checkpoint but not in the
values that gem5 source code knows about.
To do this, we must expose iteration over IniFile section keys. To not
have to make those classes public, a visitor method is implemented.
Change-Id: I23340a953f3e604642b97690a7328b10fdd740a8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37575
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
This commit makes it so LGKM count is decremented in a single place
(after completeAcc), which fixes a couple of potential bugs
1. Data is only written by completeAcc, not after initiateAcc. LGKM
count is supposed to be decremented after data is written.
2. LGKM count is now properly decremented for atomics without return
Change-Id: Ic791af3b42e04f7baaa0ce50cb2a2c6286c54f5a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39396
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The second argument in the std::max call is treated as an unsigned value
as all variables are unsigned as well. This will result in an
unsigned underflow, and as such the std::max is a no-op and will result
in the underflowed value.
The `start` and `used` value get corrupted after that, and checks for
`empty` and other stuff downstream break.
Change-Id: I00017e22ba84e65f6b1c596f47d348f342fbc304
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39496
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This ABI is also applicable for gem5 ops. Rather than have the gem5 ops
use the syscall ABI, this change exports the syscall ABI and renames it
the "reg" ABI, or in other words an ABI which only uses registers. The
SE workload class then just creates a local name for the "reg" ABI so it
can continue to use it for system calls.
Change-Id: Ifaa38a94d6f0d49b8a2e515e02ce94472a499a00
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39315
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Comparing arrays with memcmp is fairly easy to do and will correctly
identify when a value is incorrect, but gtest doesn't know what
comparison actually happened and can't print any diagnostic information
to help the person running the test determine what went wrong.
Unfortunately, gtest is also slightly too smart and also not smart
enough to make it easy to compare the contents of sub-arrays with each
other. The thing you're checking the value of *must* be an array with a
well defined size (not a pointer), and the size *must* exactly match the
number of elements it expects to find.
One fairly clean way to get around this problem would be to use the new
std::span type introduced in c++20 which lets you refer to a sub-section
of another container in place, adjusting indexing, sizing, etc as
needed. Unfortunately since we only require up to c++-14 currently we
can't use that type.
Instead, we can create vectors which hold copies of the required data.
This is suboptimal since it means we're copying around data which
doesn't really need to be copied, but it means that the templates in
gtest will get a type they can handle, and the sizes will match like it
expects them to. Since the number of checks/copies is still small, the
overhead should be trivial in practice.
A helper function, subArr, has been added to help keep things fairly
clutter free.
Change-Id: I9f88c583a6a742346b177dba7cae791824b65942
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38895
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
The functions isSet(), noneSet(), and allSet() assume that
all bits of the underlying container have a corresponding
flag. This is typically not true, and the likelihood of
incorrectly using these functions is high.
Fortunately these functions are not being used anywhere,
and can be safely removed.
Alternatively, a mask could be provided on construction to
determine which bits of the underlying container correspond
to a flag bit, so that the proper bits are checked in these
functions.
Change-Id: Ia7cbfd0726943506a3f04dc417e67a0b57cdbf95
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38736
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
This code was simplified a little while ago, and the wrong variable name
was used in that computation accidentally. Fortunately the "wrong" value
would be too large, and so nothing bad would happen except a pair of
arrays would be overly large in the O3 instruction class.
Change-Id: I9694f1a8c79a62a172ef63bdd2f98fa0ace06acd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38383
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When parsing an ISA description, the InstObjParams class needs to have a
reference to the current parser. It does that by exposing a wrapper to
the description rather than the actual InstObjParams class. That wrapper
injects an additional argument into the InstObjParams constructor.
Originally, the wrapper which injectect the additional argument was a
function which masqueraded as a class. That made it impossible to
subclass InstObjParams.
Instead, this change replaces that function wrapper with a class
wrapper, and injects the extra argument in the __init__ method. This
preserves the fact that the InstObjParams name refers to a class, and
allows any sort of interaction that's normally allowed with a class like
subclassing.
Change-Id: I550ea2e60eadac3c7c0b9afa7d71f4607b49a5d2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39275
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There is a race condition in VIPER where an atomic issued to the same
address can occur resulting in multiple trigger messages signalling the
compleition of the atomic operation. The first message was deallocating
the TBE causing the second message to dereference a nullptr when looking
up the TBE.
A counter is added to track the number of in flight AtomicDone trigger
messages. The AtomicDone is not called until the last in flight message
arrives at the trigger queue. The remaining messages call AtomicNotDone
which simply pops the message from the queue and keeps the TBE
allocated.
Change-Id: Ie1de0436861a7c393ad6d2fb2faceb83c18d4cc3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39175
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
A prior commit (f6ec145fc0) fixed early LGKM decrementing for flat loads
and stores, but failed to address flat atomics.
Per the GCN3 ISA, LGKM count is decremented on flat atomics with return
when the data has been returned. This patch checks if the flat
instruction is an atomic with return, and decrements LGKM count if so.
Change-Id: I5c0c2c205a8b21327d4c42ba71c59842c15bd63b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39155
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matthew Poremba <matthew.poremba@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Currently, the name of the stats group of thr Root object is
Stats, which is likely to be confused with the Stats namespace.
This commit renames the struct to RootStats. This allows the
Stats namespace to be expressed as `Stats::`, which is
consistent with how the namespace is accessed in other part of
gem5.
Change-Id: Ieb425c3df1f5c0d5f11b1a467a36b2e0e07b2771
Signed-off-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38915
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This prototype might convince the compiler that it should refer to
curTick indirectly through the linker, but curTick is inline (and making
it not has very high overhead), so there's a decent chance no non-inline
version will be emitted.
Change-Id: Iab5aacb145d4a974bc1bc0abdf7275c40fbb9c38
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38997
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
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 original implementation of curTick used a thread local variable,
_curEventQueue, and its getCurTick() method, to retrieve the curTick for
the currently active event queue. That meant that core.hh needed to
include eventq.hh so that the EventQueue type was available, which also
indirectly brought in a lot of other dependencies.
Unfortunately this couldn't easily be fixed by making curTick()
non-inline since this added a significant amount of overhead when
tested.
Instead, this change makes the code in core.hh/core.cc keep a pointer
directly to a Tick. The code which sets _curEventQueue now also sets
that pointer when _curEventQueue changes.
The way curTick() now reaches into the guts of the current EventQueue
directly is not great from a modularity perspective, but if curTick is
considered an extension of the EventQueue, then it's just odd that this
part is broken out into a different file.
Change-Id: I8341b40fe75e90672eb1d70e1a368975fcbfe926
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38996
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
SimplePoolManager doesn't allow mapping of two WGs
simultaneously on the same Compute Unit (provided
the previous WG has been mapped to all the SIMDs)
even if there is sufficient VRF and SRF space
available.
DynPoolManager takes care of that by dynamically
allocating and deallocating register file space
to wavefronts
Change-Id: I2255c68d4b421615d7b231edc05d3ebb27cbd66c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32034
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Alexandru Duțu <alexandru.dutu@amd.com>
