At the moment it is not possible to trace the value of VecElemClass
registers. If a AArch32 SIMD binary is run with tracing on,
simulation will fail the following assertion [1].
std::string
valString(const void *val, size_t size) const override
{
assert(size == sizeof(ValueType));
The problem is that Arm VecElems are stored in RegVal (uint64_t),
but the VecElem data type (ValueType above) per se is a uint32_t.
So valString is getting called with size = 8 (coming from RegVal)
but ValueType has size = 4. We fix this problem by using RegVal as
a VecElemRegClassOps template parameter to make them match.
This is not changing anything from a functionality perspective.
The result will be that we will be able to print VecElems as 64bit
values.
This solution is the most simple one but a bit dirty. I believe
in the long term we should make the VecElemClass use the void* interface
rather than the RegVal one. In this way we will be able to correctly
print the VecElem size as 32bit value.
[1]: https://github.com/gem5/gem5/blob/v22.1.0.0/src/cpu/reg_class.hh#L362
Change-Id: Ic3fc252d41449f828b77f938fefc0cd4274b1c57
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/70697
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Patch https://gem5-review.googlesource.com/c/public/gem5/+/70040 added
support for a variable number of SDMA engines to support newer GPU
models. As part of this an SDMA IDs map was added to map from SDMA ID
number to the SDMA SimObject pointer. In order to get the correct
pointer in unserialize now, we need to store the ID in the checkpoint
and use that to index the new map. We can't simply assign using the loop
variable as the SDMAs might not be in order in the checkpoint and
additionally the checkpoint contains both the gfx and page offset for
the SDMA engines, so each SDMA is inserted into the SDMA offset map
(sdmaEngs) twice.
Change-Id: I08e9a8d785f467b6eebff8ab0a9336851c87258d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/70878
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
The decoding function was wrongly named decodeNeon3SameExtra,
referring to the "AdvSIMD three same Extra" instruction pool
This might be an old name as I can only find the
"AdvSIMD *scalar* three same Extra" in the Arm arm. The
encoding space reserved to the pool bears the
"Advanced SIMD three-register extension" name; we
therefore rename the function to decodeNeon3RegExtension
Change-Id: I056da8f0c7808935d12a4b05490d30654178071f
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/70724
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Rather than forcing raz registers to write something like:
.raz(uint64_t(-1))
we provide a shorter version where if
no bitmask is specified we assume the entire register is
raz/rao. This won't be probably used by rao but I
am striving for symmetry and providing a default won't
probably hurt
Change-Id: I309e345fc8336df3a74474f8f9202bf7e2095b41
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/70559
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch is adding the MISCREG_UNSERIALIZE flag to expose
the user to the following checkpoint compatibility problem:
What happens when a checkpoint is restored with a different
architectural configuration?
The current behaviour is to silently restore the checkpoint
and to populate the ISA registers accordingly. However some of
these restored values will be used and some of them will
be actually discarded.
For example the value of the MISCREG_ID_AA64ISAR0_EL1 register
(initially configured at construction time [1]) will be overwritten by
the checkpointed value in ISA::unserialize (checkpointed params win over
current params). On the other hand we "discard" the checkpointed value
for registers handled in the ISA::readMiscReg method (not accessing the
storage) like MISCREG_ID_AA64PFR0_EL1 [2] (current params win over
checkpointed params).
In other words some registers will be unserialized while some others
will discard the checkpointed value in favour of the current
configuration setup. This categorization is currently implicit and it
ultimately depends on whether or not a register read access its storage
(see MISCREG_ID_AA64PFR0_EL1 above).
With this patch we formalize this distinction. We allow the developer to
be explict on which register should not be unserialized and should
instead use the new simulation parameters.
If there is a mismatch between the reset value of such register and
the checkpointed one, we warn the user and we undo the unserialization
for such register.
[1]: https://github.com/gem5/gem5/blob/v22.1.0.0/src/arch/arm/isa.cc#L437
[2]: https://github.com/gem5/gem5/blob/v22.1.0.0/src/arch/arm/isa.cc#L1019
Change-Id: Icea6563ee5816b14a097926b5734f2fce10530c7
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/70557
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This instruction has two issues. The first is that it should write two
consecutive registers, starting with vdst because it is writing two
dwords. The second is that the data assignment to the lanes from the
dynamic instruction should cast to a U32 type otherwise the array index
goes out of bounds and returns the wrong data.
The first issue was fixed in GCN3 a few years ago in this review:
https://gem5-review.googlesource.com/c/public/gem5/+/32236. This
changeset makes the same change for Vega and applies the U32 cast in
both ISAs.
Tested with rocPRIM unit test. The test was failing before this
changeset and now passes.
Change-Id: Ifb110fc9a36ad198da7eaf86b1e3e37eccd3bb10
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/70577
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Rather than recomputing the reset value every time a system
reset happens (and the ISA::clear method gets called), we
calculate it once and construction time.
We when simply apply the pre-computed reset value to the miscReg
storage, as implemented by a previous patch [1]
[1]: Change-Id: If352501738729927c1c9b300e5b0b8c27ce41b79
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Change-Id: Iecffff4878217c38707be4ce7d4746ff95a208b4
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/70465
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 patch is fixing read redirection for the MIDR register
in the following ways:
1) Is allowing a virtualization of the register (via VPIDR)
even in secure mode (available with FEAT_SEL2)
2) Is extending this logic to the AArch64 version (MIDR_EL1)
It is also rewriting the base logic using Armv8 terminology
(checking the EL rather than the mode as an example).
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Change-Id: I5cf09240206287cab877ea7ff6e46cf823aa8c35
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/70464
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
