All over gem5 the params pointers are not deleted within the classes
that they were created for. Although this is a potential memory leak
as of now, it is probably safer to follow general convention so that
it can be fixed at once in the future.
Change-Id: If96f04058d51513fa8763610880e5524785ee9cf
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24249
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
All over gem5 the params pointers are not deleted within the classes
that they were created for. Although this is a potential memory leak
as of now, it is probably safer to follow general convention so that
it can be fixed at once in the future.
Change-Id: I74b662a8e635cdfb4dc1eae732dd114659fab2e9
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24246
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
* dict methods dict.keys(), dict.items() and dict.values()
return "views" instead of lists
* The dict.iterkeys(), dict.iteritems() and dict.itervalues()
methods are no longer supported.
* map() and filter() return iterators.
* range() now behaves like xrange() used to behave, except it works with
values of arbitrary size. The latter no longer exists.
* zip() now returns an iterator.
Change-Id: Id480018239db88d7f5d60588c93719056de4a0c0
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26248
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
While the up-to-date data may reside in any agent of Ruby's memory
hierarchy, there's an optional backing store in Ruby that provides
a 'correct' view of the physical memory. When it is enabled by the
user, every Ruby memory access will update this global memory view
as well upon finishing.
The issue is that Ruby's atomic access, used in fast-forward, does
not currently access the backing store, leading to data
incorrectness. More specifically, at the very beginning stage of the
simulation, a loader loads the program into the backing store using
functional accesses. Then the program starts execution with
fast-forward enabled, using atomic accesses for faster simulation. But
because atomic access only accesses the real memory hierarchy, the CPU
fetches incorrect instructions.
The fix is simple. Just make Ruby's atomic access update the backing
store as well as the real physical memory.
Change-Id: I2541d923e18ea488d383097ca7abd4124e47e59b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26343
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Onur Kayıran <onur.kayiran@amd.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The only difference was whether the the atomic op functor was accepted
as an argument. If it wasn't, setVirt would be called without an op
functor argument where it will default to nullptr.
This change deletes the constructor which doesn't take an atomic op
functor and in the other defaults the functor to nullptr. Functionally
nothing changes, but the code is now simpler.
Change-Id: Iff06543b1046594df297344e16961ee9d0f0a373
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26231
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
The new local access mechanism installs a callback in the request which
implements what the mmapped IPR was doing. That avoids having to have
stubs in ISAs that don't have mmapped IPRs, avoids having to encode
what to do to communicate from the TLB and the mmapped IPR functions,
and gets rid of another global ISA interface function and header files.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-187
Change-Id: I772c2ae2ca3830a4486919ce9804560c0f2d596a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23188
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Add an invalidation function to the AssociativeSet, so that entries
can be properly invalidated by also invalidating their replacement
data.
Both setInvalid and reset have been merged into invalidate to
indicate users that they are using an incorrect approach by
generating compilation errors, and to match CacheBlk's naming
convention.
Change-Id: I568076a3b5adda8b1311d9498b086c0dab457a14
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24529
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When the MSHR is handling a request that will make the block dirty the
current cache commits respond. When that's not the case the cache
should forward any snoops. This CL fixes MSHR::handleSnoop() to
implement this behavior.
Change-Id: I207e3ca4968fd9528fd4cdbfb3eb95f470b4744d
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23668
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Create a function to encapsulate mapping an address in gem5's
address space to the host's address space. The returned value can
be used to access the contents of the given address.
As a side effect, make the local variable hostAddr use snake_case
to comply with gem5's coding style.
Change-Id: I2445d3ab4c7ce5746182b307c26cbafc68aa139c
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22610
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Members `tc` and `ongoingTranslation` were uninitialized in the constructor for
`QueuedPrefetcher::DeferredPacket`. If `ongoingTranslation` is not initialized to
`false` by default, some translation requests from queued prefetchers are not
properly handled and executions are nondeterministic.
Change-Id: Ia278f9e74847d6b847984d47f6a45643bae57794
Signed-off-by: Isaac Sánchez Barrera <isaac.sanchez@bsc.es>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22844
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The type of the local unique_ptr variable was different from the return type.
In C++11 because of such difference, a copy-ellision would not be possible,
and that required the use of a std::move.
In C++14 the restriction of same types being required was removed, so
std::move would not be needed anymore.
With the addition of the -Wredundant-move warning in newer compilers, having
the std::move on the return became an issue, breaking compilation.
Change-Id: I45d18dfc500bb5db5fe360814feb91853c735a19
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22403
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
