base: Make AddrRangeMap able to return non-const iterators.

The erase() method only accepts regular iterators which is consistent
with the normal STL map, but the existing find() only returns const
iterators. The STL container can return either depending on if "this"
is const.

Unfortunately there isn't a great way to have only one find
implementation which returns the right type of iterator under the right
conditions. Also, it's not possible to turn a const_iterator into an
iterator, but it is possible to go the other way. This change
duplicates very short functions which return iterators, and for find
does the only thing I could find which avoids having to copy that
whole large function.

Change-Id: I2f789b5d0881feb9adff9978bd40e31731c6a688
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/17588
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>

base: Fix includes in AddrRangeMap header file

Change-Id: I4bdd6cf7c8d22219c0582ab206ec8372a4357759
Reviewed-on: https://gem5-review.googlesource.com/11429
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>

base: Build caching into the AddrRangeMap class

Rather than have each consumer of the AddrRangeMap implement caching
lookups on their own, this change adds a centralized mechanism to the
AddrRangeMap class itself.

Some benefits of this approach are that the cache handles deleted
entries correctly/automatically, the cache is maintained by
adding/removing entries from a linked list rather than moving elements
in an array and checking valid bits, and it's easy to enable in places
which might otherwise not bother with caching. The amount of caching
is tunable to balance overhead with improved lookup performance.

Change-Id: Ic25997e23de4eea501e47f039bb52ed0502c58d2
Reviewed-on: https://gem5-review.googlesource.com/5242
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>

base, mem: Disambiguate if an addr range is contained or overlaps

We need to determined whether an address range is fully contained or
it overlaps with an address range in the address range in the mmap. As
an example, we use address range maps to associate ports to address
ranges and we determine which port we will forward the request based
on which address range contains the addresses accessed by the
request. We also need to make sure that when we add a new port to the
address range map, its address range does not overlap with any of the
existing ports.

This patch splits the function find() into two functions contains()
and intersects() to implement this distinct functionality. It also
changes the xbar and the physical memory to use the right function.

Change-Id: If3fd3f774a16b27db2df76dc04f1d61824938008
Reviewed-on: https://gem5-review.googlesource.com/11115
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>

mem: Add interleaving bits to the address ranges

This patch adds support for interleaving bits for the address
ranges. What was previously just a start and end address, now has an
additional three fields, for the high bit, and number of bits to use
for interleaving, and a match value to compare against. If the number
of interleaving bits is set to zero it is effectively disabled.

A number of convenience functions are added to the range to enquire
about the interleaving, its granularity and the number of stripes it
is part of.

base: Simplify the AddrRangeMap by removing unused code

This patch cleans up the AddrRangeMap in preparation for the addition
of interleaving by removing unused code. The non-const editions of
find are never used, and hence the duplication is not needed.

base: Encapsulate the underlying fields in AddrRange

This patch makes the start and end address private in a move to
prevent direct manipulation and matching of ranges based on these
fields. This is done so that a transition to ranges with interleaving
support is possible.

As a result of hiding the start and end, a number of member functions
are needed to perform the comparisons and manipulations that
previously took place directly on the members. An accessor function is
provided for the start address, and a function is added to test if an
address is within a range. As a result of the latter the != and ==
operator is also removed in favour of the member function. A member
function that returns a string representation is also created to allow
debug printing.

In general, this patch does not add any functionality, but it does
take us closer to a situation where interleaving (and more cleverness)
can be added under the bonnet without exposing it to the user. More on
that in a later patch.

AddrRange: Transition from Range<T> to AddrRange

This patch takes the final plunge and transitions from the templated
Range class to the more specific AddrRange. In doing so it changes the
obvious Range<Addr> to AddrRange, and also bumps the range_map to be
AddrRangeMap.

In addition to the obvious changes, including the removal of redundant
includes, this patch also does some house keeping in preparing for the
introduction of address interleaving support in the ranges. The Range
class is also stripped of all the functionality that is never used.