When building with clang with the --without-tcmalloc flag set, the
-fno-builtin flag is not used, and clang can then detect that the
integer version of abs(), apparently the C version, is being used on a
floating point value in traffic_gen.cc.
This change takes clang's suggestion to use std::abs instead, and also
includes a header file which will provide it.
Change-Id: Ic28ed7454b2ac00c89328d9d0314aed74e946643
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41597
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The name of the build is opt, so it should be fully optomized. Also, the
fast build, the only one with LTO historically, is dangerous to use
since it disables many error checks. I personally run gem5 many times
while developing, iterating and trying to fix bugs, and so want it to
run quickly then too, not just the final time when collecting results.
Also, since they mirror the opt build, the perf and prof builds also
have LTO options added.
This has the nice side effect of speeding up the build time of build/X86
significantly (6:20 -> 4:27) due to parallelization of the link, and
reduces the size of the build/X86 directory (with debug compression
enabled) from 3.4GB to 2.8GB.
The size of build/X86/python/_m5 is still 1.6GB, so still more than half
of the total size of build/X86.
Change-Id: I8feabf99454693fdd100d9e1a64fdeae53362f75
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40815
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Earl Ou <shunhsingou@google.com>
The operators it seems to need are ones which modify the BitUnion being
operated on, vs ones which just use it to produce a new value. The later
kind can be handled by converting the BitUnion into its underlying type
and then applying the built in operators.
Change-Id: I8aa08bf74d8ad88f4dfbb0031610c52ad412d03b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41515
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The TBEStorage is used to track the resources consumed by the TBETable,
i.e. the number of available TBE slots.
structure(TBEStorage, external ="yes") {
int size();
int capacity();
int reserved();
int slotsAvailable();
bool areNSlotsAvailable(int n);
void incrementReserved();
void decrementReserved();
int addEntryToNewSlot();
void addEntryToSlot(int slot);
void removeEntryFromSlot(int slot);
}
TBEStorage resource tracking has two main differences from TBETable:
1) Allows slot reservation. This is useful to implement protocols that
employ retry/credit messages instead of stall when the controller runs
out of TBEs to accept new request.
2) Can also assign multiple entries to the same slot. This is useful to
more easily model cases where multiple transactions share the same TBE
resource (i.e. the slot).
E.g: a request that triggers a replacement in a system without
dedicated WB/Eviction buffer; both transactions can can have separate
logical TBEs associated to the same slot.
The motivation for having a separate structures for tracking TBEs
availability are twofold:
- Keeps TBETable simple and without the additional overhead for
protocols that do not need these additional features.
- Having two separate transactions sharing the same TBE resource using
the current TBETable would be cumbersome since the TBETable is indexed
by the transaction address.
Change-Id: I64106d50068320bc925243732ef8ff9ef0b6c4bf
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41157
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
In the background, scons invokes commands using what is essentially
'sh -c ${CMD}'. It's a little more sophisticated than that, but the net
effect is that all of the arguments of a given command are collected
into a single argument for sh. While Linux has a very generous limit
on the number of command line arguments you can have, and a relatively
generous limit on the total size of the arguments and environment
variables which can be read with "getconf ARG_MAX" (about 2MB only my
system), the limit on an individual argument, defined in the little
documented constant MAX_ARG_STRLEN, is much smaller, 32 pages or
131072 bytes from what I've read.
Unfortunately, when building gem5, especially without partial linking,
the command line for the final linking step can be very long, and with
some extra files brought in with EXTRAS can relatively easily exceed
this limit.
To work around this problem, this change adds a new scons "tool" which
replaces the SPAWN and PSPAWN construction environment variables (not
the shell environment, scon's env, aka main) with wrappes. These
wrappers create a temporary file, write the command into it, and then
tell the original SPAWN/PSPAWN implementation to run that file as the
actual command.
This works, but it has two potential drawbacks. First, it creates
extra temporary files which may add some overhead to the build. The
overhead is likely small, but is non-zero.
Second, while this restores the original breaks between command line
arguments, it doesn't completely avoid the total argument/environment
size limit which would be harder to hit, but does still exist.
Another option would be to use the same sort of technique, but to use
gcc's (and I assume clang's) ability to read options from a file using
an @file argument, where file is replaced with the name of the
arguments.
The upside of this approach is that it avoids all of these limits
since gcc is just reading a file, and the only limits are ones it self
imposes. Also, this would only apply to invocations of gcc, and so
would be worth plumbing in to only affect, say, the linking step.
There would be no hypothetical overhead from creating temp files.
One downside though, is that this is not a universal approach and
would break anything which doesn't understand @file style arguments.
Also, when intercepting calls to the shell, the arguments we're
getting have been made appropriate for that environment (escaping,
quoting, etc). The rules for escaping arguments in an @file may not be
quite the same as for the shell, and so there may be weird cases where
a command line gets garbled this way.
Given the tradeoffs, I think always putting the commands into temp
files and running them as scripts is the way to go.
Change-Id: I0a5288aed745a432ed72ffd990ceded2b9422585
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41273
Reviewed-by: Earl Ou <shunhsingou@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This very small kernel module seems to be intended to measure the access
time to device registers when running in a linux kernel. It mentions
kernel version 2.6.x and so is fairly old and may not work with modern
kernels.
While there is probably some utility (no pun intended) to having a
driver like that and that sort of measurement capability, the usefulness
is probably not huge compared to its small but non-zero maintenance
burden. It seems like it's not something that gets active attention
given it's revision history, and is probably just taking up space these days.
Change-Id: I3b1f44d718d7e6ee23695e3117bb169268f2157a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41473
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This script is basically a wrapper around scons. Since scons is already
a pretty robust python based build environment, there doesn't seem to be
much need to add another python wrapper around it.
Also, this script is quite out of date. For instance, it only mentions
SPARC and MIPS (it used to mention ALPHA, but that was deleted), and
still makes reference to separate _FS and _SE builds which haven't been
a thing for many years.
Change-Id: I0e9fefaa5b3c2d092f70ad01b904eb7e64e5361e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41455
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Add a DMA thread tester to the Ruby GPU tester to test the DMA state
machine in the protocol. Currently creates a dummy DMA device to pass
through Ruby.py and scans for the DMA sequencers due to opaqueness of
Ruby.py.
DMA atomics not yet supported as there is no protocol that implements
atomic transitions in the DMA state machine file.
Example run command:
build/GCN3_X86/gem5.opt configs/example/ruby_gpu_random_test.py \
--test-length=1000
Change-Id: I63d83e00fd0dcbb1e34c6704d1c2d49ed4e77722
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39936
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When calling TryCompile with an empty string for the source, useful
when just testing a build flag, some versions of SCons will apparently
create some sort of equivalence between Value('') and Value(0). That
shows itself when creating config file headers, where Value(0) is
switched with Value(''), and the header defines a macro with which
expands to nothing rather than a macro which expands to 0. Later uses
of the macro of the form:
#if CONFIG_VARIABLE
fail because CONFIG_VARIABLE expands to nothing. If it expanded to 0
like it's supposed to, then the guarded block of code would be excluded
correctly.
Change-Id: Ie324ec5f8dd307c65745b9326a11230e10caa0bd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41213
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
While the wakeUpBuffers/wakeUpAllBuffers check all message buffers,
wakeup_port wakes up only the messages stalled on the specified port
and address. Usage is the same as the stall_and_wait statement, e.g.:
wakeup_port(reqInPort, addr);
Change-Id: I57dc77d574c0016ca55786ce16a73061a1d37f2e
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41155
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Certain branch instructions specify that the result of (simm16 * 4)
gets sign-extended before being added to the PC.
Previously, that result was being sign extended as if it was still a
16-bit number. This patch fixes that by having the result be sign
extended as an 18-bit number.
Change-Id: Id4d430f8daa71ca7910b570e7e39790626f1decf
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41053
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 original implementation had a function we'd call back into later
which checked if a given ISA has KVM support on the current host.
Instead, this change reverse that and statically figures out which
single target ISA could possibly run under KVM on this host. Then later,
we can just check if the ISA we're trying to build is that one.
Change-Id: I3e7e06180983dfcc4611181718eb5d6210844d36
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40870
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Collapse nesting, and constrain the try/except to only the line in that
section which might actually be expected to throw an exception when
things are working normally.
This makes the code easier to read, and won't absorb and discard
exceptions which are thrown for unexpected reasons.
Change-Id: Id3ac417ab5545bef35ed8a87d05211c8ef2f5a50
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40867
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Collapse the check_hdf5 to the only place it was called, to set a simple
flag variable. Pull the invariant have_pkg_config check out of
check_hdf5_pkg, since if we don't have pkg-config there's no reason to
even try to use to set up hdf5. Turn the one-off, non-standard "Warning"
print into an actual warning().
Change-Id: I04793ae862aeaf1605467d205837b9dd744f93cb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40865
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
There are really only two options current, glibc or none. If there's a
working implementation there's no real reason to select none, and if
there isn't there's no other option but to select none.
Instead of building up a list, having a default, and making what option
on the list is selected configurable, boil it down to either using glibc
if that implementation is detected, or warning and using none. Also
merge the "normal" and *BSD versions of the checks to reduce redundancy.
The complexity can be added back in if/when there are other
implementations to choose from.
Change-Id: I27c77996a00018302f4daea40924cf059d5a4323
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40864
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
These functions where correctly returning whether a flag had existed,
and also correctly not installing it if asked not to. Unfortunately if
they *were* asked to install the flag, they ignored whether or not it
had actually existed to begin with.
Change-Id: I2dca0e1a0ddbc182576d48237aeea5452a02c51b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41159
Maintainer: Gabe Black <gabe.black@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
