On Mon, 6 Jul 2015, Giacomo Gabrielli wrote:
----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2828/#review6715 ----------------------------------------------------------- These are my current thoughts about this patch: 1. My impression is that there is still not enough architectural support to understand if the new vector register type as it stands can address all the different corner cases efficiently; I'd leave to the wider gem5 community decide where we want to draw that line...
Can you elaborate what corner cases might we run into? I have reimplemented SSE instructions using the new type, and I did not find the new type to be limiting in any sense.
2. Legacy SSE requires merging of upper lanes, while AVX does zeroing; also ARMv8 AArch64 scalar FP and NEON instructions perform zeroing. Assuming that destination vectors are always read is going to introduce unneded serialization for those ISA extensions if they are going to be ported to the new scheme, so I'd suggest to avoid to implicitly read on write. Also for cases where merging is required, maybe something smarter should be done to avoid unneded serialization; without optimizations, any sequence of x86 FP scalar instructions could be significantly slow compared to real hw implementations.
Instructions for which the whole register would be written should be able to avoid reading the initial register. For scalar operations, I agree that we would be reading and writing many more bytes than required. Do you have any suggestions?
-- Nilay _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
