On Wed, 16 Oct 2013, Steve Reinhardt wrote:
I think I've figured this out. This max_in_port_rank value is computed
using a Python class variable on the InPortDeclAST class; it's initialized
to zero, then every time a port is declared it updates the max rank as
necessary. The problem arises because the SLICC parser is not invoked as a
separate process, but is just imported into the scons instance of the
Python interpreter. Thus when you build binaries encompassing multiple
protocols in a single scons invocation (as you do for regressions), you
actually end up with this being the max value across all the protocols that
have been parsed thus far. Throw in some concurrency with '-j', and it's
not just dependent on the set of protocols you're building, it's also
non-deterministic. If you're only compiling one protocol, you get the
right answer, and it's stable, which is why most people probably don't
notice this.
Since it's only setting the max size for the vector of message buffers,
having the value be too large doesn't impact the correctness of the
simulation either. The real problem is just that it's causing spurious
rebuilds (and regression re-runs).
It seems like there are several ways to fix this:
1. Invoke SLICC as a separate process for each protocol.
2. Find a different way to calculate the max rank that localizes it to a
specific protocol.
3. Tweak Ruby to not need this value.
Initially #1 seemed like the obvious path to me, but looking at where
m_max_in_port_rank is used (only in two places in AbstractController.cc), I
don't think #3 would be that bad either. Basically this value seems to be
used to move a couple of loops up into AbstractController by guaranteeing
that those loops cover the worst-case bounds of any derived class. It
seems like it wouldn't be that hard to pass the actual in-port rank for a
derived class up into AbstractController via a constructor argument
instead, and then we wouldn't even need this whole calculation. Does that
make sense? Any other opinions?
I think we can replace m_max_in_port_rank with the number of in ports. I
do not see why it would be the case that different inports have same
rank or there is no port for a particular rank.
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
