In the RISC-V system, we need to VecClassReg to run RISC-V vector
instruction, and VecElemReg is not applicable because the element length
of vector can be resizable via vset\*vl\* instruction.
The change will seperate the reg_index for VecReg and VecElemReg to
ensure that have the space for VecReg when VecElemReg is not applicable.
When an Evict request is received from upstream for a shared line and
the line is no longer cached locally (or on any other upstream cache),
we need to also send an Evict downstream. In this case we need to wait
until our outgoing Evict completes before completing the Evict from
upstream in order be able to resolve race conditions with incoming
snoops. E.g.: while our outgoing Evict is pending we may receive a snoop
requesting data, but we won't be able to complete this snoop if we have
already completed all upstream Evicts and we no longer have the line.
In the RISC-V system, we need to VecClassReg to run RISC-V vector
instruction, and VecElemReg is not applicable because the element
length of vector can be resizable via vset*vl* instruction.
The change will seperate the reg_index for VecReg and VecElemReg to
ensure that have the space for VecReg when VecElemReg is not
applicable.
Change-Id: I99a82dec273baeee31df89a0ee0f5e87f3ff187c
There are a few LDS instructions that perform local ALU operations and
writeback which are marked as loads. These are marked as loads because
they fit in the pipeline logic better, according to a several year old
comment. In the VEGA ISA these instructions (swizzle, permute, bpermute)
are not decrementing the LDS load counter. As a result, the counter will
gradually increase over time. Since wavefront slots are persistent, this
can cause applications with a few thousand kernels to eventually hang
thinking there are not enough resources.
This changeset fixes this by decrementing the LDS load counter for these
instructions. This fix was already integrated in the GCN3 ISA in the
exact same way. This changeset moves it near a similar comment about
scheduling register file writes.
Change-Id: Ife5237a2cae7213948c32ef266f4f8f22917351c
When an Evict request is received from upstream for a shared line
and the line is no longer cached locally (or on any other upstream
cache), we need to also send an Evict downstream. In this case we need
to wait until our outgoing Evict completes before completing the Evict
from upstream in order be able to resolve race conditions with incoming
snoops. E.g.: while our outgoing Evict is pending we may receive a
snoop requesting data, but we won't be able to complete this snoop if
we have already completed all upstream Evicts and we no longer have the
line.
Change-Id: I23ac4f0a9c4ddd81e2425376c8d1e1c7fb66d107
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
1. The current SignalSinkPort and SignalSourcePort have no
ways to assign the init value of the state. Add a new constructor
for them with the param init_state
2. After the source and sink are bound, the state at both side should
be the same. Set the the state of sink to the state of source in the
bind() function.
Change-Id: Idde0a12aa0ddd0c9c599ef47059674fb12aa5d68
Compilation bug found on:
https://github.com/gem5/gem5/actions/runs/5899831222/job/16002984553
In gcc Version 8 and below the following error is received:
```
src/base/bitfield.hh: In function ‘constexpr int gem5::findLsbSet(uint64_t)’:
src/base/bitfield.hh:365:34: error: call to non-‘constexpr’ function ‘int gem5::{anonymous}::findLsbSetFallback(uint64_t)’
return findLsbSetFallback(val);
~~~~~~~~~~~~~~~~~~^~~~~
scons: *** [build/ALL/kern/linux/events.o] Error 1
```
`findLsbSet` cannot be `constexr` as it calls non-constexpr function
`findLsbSetFallback`. `findLsbSetFallback`. The problematic function is
the `count` on the std::bitset.
This patch changes this to a constexpr.
Compilation bug found on:
https://github.com/gem5/gem5/actions/runs/5899831222/job/16002984553
In gcc Version 8 and below the following error is received:
```
src/base/bitfield.hh: In function ‘constexpr int gem5::findLsbSet(uint64_t)’:
src/base/bitfield.hh:365:34: error: call to non-‘constexpr’ function ‘int gem5::{anonymous}::findLsbSetFallback(uint64_t)’
return findLsbSetFallback(val);
~~~~~~~~~~~~~~~~~~^~~~~
scons: *** [build/ALL/kern/linux/events.o] Error 1
```
`findLsbSet` cannot be `constexr` as it calls non-constexpr function
`findLsbSetFallback`. `findLsbSetFallback`. The problematic function is
the `count` on the std::bitset.
This patch changes this to a constexpr.
Change-Id: I48bd15d03e4615148be6c4d926a3c9c2f777dc3c
When a linux kernel changes a page property, it flushes the related cache
lines. The kernel might change the page property before flushing the
cache lines. This results in the clflush might occur in an uncacheable region.
Currently, an uncacheable request must be a read or a write. However,
clflush request is neither of them.
This change aims to allow clflush requests to work on uncacheable regions.
Since there is no straightforward way to check if a packet is from a clflush
instruction, this change permits all Clean Invalidate Requests, which is
the type of request produced by clflush, to work on uncacheable regions.
Change-Id: Ib3ec01d9281d3dfe565a0ced773ed912edb32b8f
Signed-off-by: Hoa Nguyen <hn@hnpl.org>
In this case the function is turned into a generator with the
"yield" of the generator the return the function's execution.
Change-Id: I4b06d64c5479638712a11e3c1a2f7bd30f60d188
On RISC-V when trap occurs the contents of PC register contains the
address of instruction that caused that trap (as opposed to the address
of instruction following it in instruction stream). Therefore this commit
does not advance the PC before reporting trap in SE mode.
Change-Id: I83f3766cff276312cefcf1b4ac6e78a6569846b9
Due to inverted logic in POWER fault handlers, unimplemented opcode and
trap faults did not report trap to GDB (if connected). This commit fixes
the problem.
While at it, I opted to use `if (! ...) { panic(...) }` rather than
`panic_if(...)`. I find it easier to understand in this case.
Change-Id: I6cd5dfd5f6546b8541d685e877afef21540d6824
The mem instructions usually executed from initiateAcc. We also need
to check vector required in those instructions
Change-Id: I97b4fec7fada432abb55ca58050615e12e00d1ca
Detected via this failing workload:
https://github.com/gem5/gem5/actions/runs/5861958237
Ir caused the following compilation error to be thrown:
```
src/arch/x86/kvm/x86_cpu.cc:1462:22: error: unused variable ‘rv’ [-Werror=unused-variable]
1462 | bool rv = isa->cpuid->doCpuid(tc, function, idx, cpuid);
| ^~
```
`rv` is unused in the .fast compilation as it's only used in the
`assert` statement immediately after.
To fix this, the `[[maybe_unused]]` annotation is used.
Detected via this failing workload:
https://github.com/gem5/gem5/actions/runs/5861958237
It caused the following compilation error to be thrown:
```
src/arch/x86/kvm/x86_cpu.cc:1462:22: error: unused variable ‘rv’ [-Werror=unused-variable]
1462 | bool rv = isa->cpuid->doCpuid(tc, function, idx, cpuid);
| ^~
```
`rv` is unused in the .fast compilation as it's only used in the
`assert` statement immediately after.
To fix this, the `[[maybe_unused]]` annotation is used
Change-Id: Ib98dd859c62f171c8eeefae93502f92a8f133776
The previous exit event occurs when the dispatcher sends a completion
signal for a kernel, but gem5 does some kernel-based stats updates after
the signal is sent. Therefore, if these exit events are used as a way to
dump per-kernel stats, some of the stats for the kernel that just ended
will be in the next kernel's stat dump which is misleading.
This patch moves the exit event to where the stats are updated and only
exits if the dispatcher has requested a stat dump to prevent situations
where stats are updated mid-kernel.
Change-Id: I74dc1cad5fc90382a2a80564764b3e7c9fb65521
We're seeing some occasional connection timeouts in CI, possibly when we
aggressively hit the license server, so let's add a parameter to retry
the connection a few times.
Also, print the time required to connect to the server to help debug
issues.
When xbar encounters the address error, print out the port trace in the
packet for user to debug if the port trace is enabled.
To gain the packet of the access, the parameter of findPort() function
is changed from AddrRange to PacketPtr.
When running gem5 with "--debug-flags=PortTrace", we can see the full
path of the unexpected access when xbar cannot find the destination of
the address.
This patch changes the data type used for image size from int
to uint64_t. Current version allows initializing AbstractMemory
types with a maximum binary size of 2GiB. This will be limiting
in many studies.
Change-Id: Iea3bbd525d4a67aa7cf606f6311aef66c9b4a52c
The previous exit event occurs when the dispatcher sends a completion
signal for a kernel, but gem5 does some kernel-based stats updates after
the signal is sent. Therefore, if these exit events are used as a way to
dump per-kernel stats, some of the stats for the kernel that just ended
will be in the next kernel's stat dump which is misleading.
This patch moves the exit event to where the stats are updated and only
exits if the dispatcher has requested a stat dump to prevent situations
where stats are updated mid-kernel.
Change-Id: I74dc1cad5fc90382a2a80564764b3e7c9fb65521
We're seeing some occasional connection timeouts in CI, possibly
when we aggressively hit the license server, so let's add a
parameter to retry the connection a few times.
Also, print the time required to connect to the server to help
debug issues.
Change-Id: I804af28f79f893fcdca615d7bf82dd9b8686a74c
1. Add findPort(PacketPtr pkt) for getting the port trace from the Packet.
Keep the findPort(AddrRange addr_range) for recvMemBackdoorReq(...)
2. With the debug flag `PortTrace` enabled, user can see the full path of
the packet with the corresponding address when address error in xbar.
Change-Id: Iaf43ee2d7f8c46b9b84b2bc421a6bc3b02e01b3e
In an SMT CPU, upon a squash, the mis-predicted(squashing) instructions
can still be executing at IEW and own phys registers. If these registers
are added back to the rename freelist on this Tick, the registers may be
renamed to be used by other SMT thread(s). This causes register
ownership hazards, which may eventually freeze the CPU. This problem
seems to date back to 2014
(https://www.mail-archive.com/gem5-users@gem5.org/msg10180.html).
This patch delays the freelist update to avoid the hazard.
I tested that this patch does not cause any performance impact for my
set of benchmarks on default non-SMT O3CPU.
In an SMT CPU, upon a squash, the phys regs used by
mispredicted instructions can still be owned by executing
instructions in IEW. If the regs are added back to freelist
on this tick, the reg may be renamed to be used by another
SMT thread. This causes reg ownership hazard, which may
eventually freeze the CPU.
This patch delays the freelist update to avoid the hazard.
Change-Id: I993b3c7d357269f01146db61fc8a7b83a989ea45
This merges initial support for RVV. Currently, only the simple CPUs are supported.
The decoder stalls for every vsetvl instruction.
In the future, we will implement vsetvl as a control instruction as described in #144
