On Fri, 22 May 2015, Giacomo Gabrielli wrote:
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2828/#review6384
-----------------------------------------------------------
Hi, I'm Giacomo and I've been working on ARMv8 support in the past
(including NEON), and I'd like to share some thoughts on this patch. In
general, I like the idea of adding a vector type, as it's going to be a
more future-proof solution, and ARMv8 code could benefit as well from
that... but I have a few concerns regarding this code as it stands
currently:
The patches have been put up so as to get a discussion going. I am
personally confident that an std::array of some size is enough for
purposes. The size may need to be adjusted with time though.
1. The patch doesn't address the problem of overlapping registers (for
now it's only xmm's & ymm's, but zmm's are likely to join the party
soon); in this context, it's not clear to me if we'd need something
fundamentally different already at this stage to address that - the
risk is to upstream this code and then later discover that we need a
different strategy for overlapping. Maybe just having a plan on how
to address that in the future could be enough at this stage?
I am working on overlapping xmm and ymm registers. Again, these patches
were put together to get a discussion going on vector operations. I am
willing to making extensive changes to these patches. Currently I am
trying to rewrite SSE instructions in gem5 so that they use vector
registers. As of now, I think it is just putting in enough time into the
activity. I do not see any major problems arising. These patches (other
than the decoder) would not be committed till we have at leaset SSE
instructions working with vector registers.
2. In the interim we would have broken SSE-AVX/AVX-2 interworking. Now
here I'm not sure where the gem5 community draws the line in terms of
ISA correctness vs. getting code out of the door for early
experiments, etc. :) At least it would be good to have some thoughts
from the wider gem5 community here...
As I wrote above, we would not commit the patches till we have everything
working at least of the instructions that already exist in gem5. But I do
want people to know the direction that we are taking.
3. I guess adding vectors could enable implementing AVX-512, and
potentially it could also enable research into more wacky
"vector-style" architectures, which means that potentially the
vectors could be REALLY wide. For this reason, I'm a bit concerned
about passing around all those vectors by value. How about changing
the register access API to return by ref when accessing vectors? (not
quite sure about the implications of that on the rest of the code
base though, but I think we'd need to somehow address the efficiency
problem).
I agree with you that we should not be passing these wide values by
copying them. I would try to change the api.
--
Nilay
_______________________________________________
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
