tech-vector-ext@lists.riscv.org

Home Messages Hashtags Subgroups

Messages

Between

and

Minutes of 2020/3/6 vector task group meeting

Date: 2020/3/6 Task Group: Vector Extension Chair: Krste Asanovic Number of Attendees: ~21 Current issues on github: https://github.com/riscv/riscv-v-spec Note, the Zoom meeting details have changed.

By Krste Asanovic · #27 ·

Reminder vector TG meeting Friday March 6th, details on members calendar <eom>

By Krste Asanovic · #26 ·

Minutes from 2/21 meeting

Date: 2020/2/21 Task Group: Vector Extension Chair: Krste Asanovic Number of Attendees: ~13 Current issues on github: https://github.com/riscv/riscv-v-spec Note, the Zoom meeting details have

By Krste Asanovic · #25 ·

EPI intrinsics reference and compiler updated to 0.8

Hi all, we have updated to version 0.8 of V-ext our LLVM-based experimental compiler and the intrinsics reference. EPI builtins and examples:

By Roger Ferrer Ibanez · #24 ·

Re: RISC-V Vector Task Group: fractional LMUL

I left the encoding unspecified in the proposal. That was intentional as I saw various tradeoffs. However, I now recommend the codes be in order of increasing VLMAX value as so:

By David Horner · #23 ·

Re: RISC-V Vector Task Group: fractional LMUL

Special lmul code in vsetvl{i} to derive LML from existing SEW/LMUL and provided sew code. As mentioned in the TG we suggested widen LMUL to 3 bits with 7 (explicit) states.

By David Horner · #22 ·

updates to vector spec repo on github

I added the change to add a vcsr including FP fields (this came out much cleaner I think) - please check over. Another minor change was to fold in the suggestion to move VS to a two-bit wide gap

By Krste Asanovic · #21 ·

Re: RISC-V Vector Task Group: fractional LMUL

I'm realizing the idea doesn't quite work unless machine actually stores the fractional LMUL value (to cope with SLEN and widening instruction behavior), and so would need the new instruction and

By Krste Asanovic · #20 ·

Re: RISC-V Vector Task Group: fractional LMUL

Could a fractional LMUL circumvent the constraint that a widening instruction's output register group must be larger than its input register group(s)? --Nick Knight

By Nick Knight · #19 ·

RISC-V Vector Task Group: fractional LMUL

In the last meeting, we discussed a problem that would be introduced if we were to drop the fixed-size (b/h/w) variants of the vector load/stores and only have the SEW-size (e) variants. From

By Krste Asanovic · #18 ·

Minutes from 2020/1/24 meeting

Date: 2020/1/24 Task Group: Vector Extension Chair: Krste Asanovic Number of Attendees: ~20 github: https://github.com/riscv/riscv-v-spec Outstanding items from prior meeting: #362/#354, #341,

By Krste Asanovic · #17 ·

Re: Slidedown overlapping of dest and source regsiters

Oops, yes, I meant vslide1down. Using vslide1down isn't about performance; it's the only way I know of for the debugger to construct a vector without additional storage. The alternative would have

By andrew@... · #16 ·

Re: Slidedown overlapping of dest and source regsiters

I'm curious why you chose to be symmetrical (no need), and why you decided incrementing for slideup decrementing for slidedn (I would do the opposite). By incrementing for vslidedown, and

By Guy Lemieux · #15 ·

Re: Slidedown overlapping of dest and source regsiters

Thanks Guy for the explanation, but my implementation is both incrementing element index for slideup and decrementing element index for slidedown (which is symmetrical implementation and simplest from

By Thang Tran · #14 ·

Re: Slidedown overlapping of dest and source regsiters

Hi Thang, I think Andrew is suggesting that the vslideup restriction is there to allow some flexibility with implementations. However, one of (vslideup/vslidedown) needs to allow the same source/dest

By Guy Lemieux · #13 ·

Re: Slidedown overlapping of dest and source regsiters

Hi Andrew, I do not understand your statement. Why is it important? Why is the difference with slideup? The slideup cannot clobber the source operand with destination operand because the

By Thang Tran · #12 ·

Re: Slidedown overlapping of dest and source regsiters

It's important that the slidedown instruction can overwrite its source operand. Debuggers will use this feature to populate a vector register in-place without clobbering other architectural state.

By andrew@... · #11 ·

Slidedown overlapping of dest and source regsiters

The slideup instruction has this restriction: The destination vector register group for vslideup cannot overlap the source vector register group or the mask register, otherwise an illegal instruction

By Thang Tran · #10 ·

Re: Calling Convention for Vector ?

Oh, heck [*]: Callee saved registers of any form can have bad performance where there is a potential partial register issue. E.g. on an out of order machine with register renaming. Although even

By Andy Glew Si5 · #9 ·

Re: Calling Convention for Vector ?

Providing callee-saved vector registers in the regular C calling convention might actually degrade performance, as most vector computation is done in leaf functions or in strip-mine loops that don't

By andrew@... · #8 ·

861 - 880 of 887

Home Hashtags Subgroups Terms