search for: hwacha

...512bits for example). That could be replaced by > a single "stepvector" constant, and it works the same for both > fixed-length and scalable vectors. Indeed! For this particular point, I think we should start there. Also, on a more general comment regarding David's point about Hwacha, maybe we could get some traction on the RISC-V front, to see if the proposal is acceptable on their end, since they're likely to be using this in the future in LLVM. Alex, any comments? cheers, --renato

...er). Indeed, no IR changes beyond those proposed for SVE support appear to be necessary to implement this approach to RISC-V vector extension support. However, this approach is wasteful, as a tailored configuration can improve performance and energy efficiency significantly. As one data point, the Hwacha project reported [4] up to 9.5% fewer cycles taken and up to 11% less energy consumed on a microarchitecture built to exploit narrower bit widths of vector elements (comparing "mvp, packed: yes" to "mvp, packed: no"). Besides such microarchitectural optimizations, enabling fewer...

...yond those > proposed for SVE support appear to be necessary to implement this approach > to RISC-V vector extension support. > > However, this approach is wasteful, as a tailored configuration can > improve performance and energy efficiency significantly. As one data point, > the Hwacha project reported [4] up to 9.5% fewer cycles taken and up to 11% > less energy consumed on a microarchitecture built to exploit narrower bit > widths of vector elements (comparing "mvp, packed: yes" to "mvp, packed: > no"). Besides such microarchitectural optimizations,...

...SVE support appear to be necessary to implement this approach to >> RISC-V vector extension support. >> >> However, this approach is wasteful, as a tailored configuration can >> improve performance and energy efficiency significantly. As one data point, >> the Hwacha project reported [4] up to 9.5% fewer cycles taken and up to 11% >> less energy consumed on a microarchitecture >> built to exploit narrower bit widths of vector elements (comparing >> "mvp, packed: yes" to "mvp, packed: no"). Besides such microarchitectur...

...ed, no IR changes beyond those proposed for SVE support appear to be necessary to implement this approach to RISC-V vector extension support. However, this approach is wasteful, as a tailored configuration can improve performance and energy efficiency significantly. As one data point, the Hwacha project reported [4] up to 9.5% fewer cycles taken and up to 11% less energy consumed on a microarchitecture built to exploit narrower bit widths of vector elements (comparing "mvp, packed: yes" to "mvp, packed: no"). Besides such microarchitectural optimizations, enabling...

On 28 November 2016 at 09:15, Alex Bradbury <asb at asbradbury.org> wrote: > The RISC-V vector proposal is still in the development stage, but it > will inevitably be vector length agnostic much like Hwacha. Krste gave > a talk about his proposal for the 'V' extension last year > <https://riscv.org/wp-content/uploads/2015/06/riscv-vector-workshop-june2015.pdf> > and I'm looking forward to his update at the RISC-V Workshop this > Wednesday, not least because I'm hoping...

I have posted a patch that switches the API to one that supports this (yet non-existent functionality) earlier: https://reviews.llvm.org/D24631 The comments from that were incorporated into the following RFC. Motivation: Certain targets feature "variable-sized" registers, i.e. a situation where the register size can be configured by a hardware switch. A common instruction set

On 27 November 2016 at 13:59, Paul Walker <Paul.Walker at arm.com> wrote: > Thanks Renato, my takeaway is that I am presenting the design out of order. So let's focus purely on the vector length (VL) and ignore everything else. For SVE the vector length is unknown and can vary across an as yet undetermined boundary (process, library....). Within a boundary we propose making VL a