Hey everyone! Late to the party. Life happens sometimes ;) Just discovered this patch and this mail list, and I'd like to provide some background story here. <https://github.com/plctlab/plct-qemu/tree/plct-riscv-backend-rvv>I originally provided my initial implementation in a downstream repo last year, namely https://github.com/plctlab/plct-qemu/tree/plct-riscv-backend-rvv . I'm new to contributing to qemu and also take part in the open-source community upstreaming process as a whole, so I may make mistakes in my following claims, but I see some confusion here: 1. The PLCT branch (which includes my original commits) is open-sourced using GPLv2, which follows QEMU's upstream repo. So according to the license, my modification should be EXPLICITLY shown in the patch, but I haven't seen any. 2. I do consent upstreaming my patch last year, in the form of a patch submitted with modifications from T-head, and on behalf of them. And it was agreed back in the days that I can be mentioned as one of the authors. But it turns out that there's no "sign-off", "author", "co-author" line mentioning me. If I don't speak out in this situation, does it imply that this patch is purely LIU Zhiwei's work and have nothing to do with me?
I'd like LIU to separate my patch and his modification to two separate patches, and explicitly name where are those patches coming from, so that this patch can comply to GPLv2 license and can we clarify those misunderstandings. I don't want to take it personally , but I do smell something's wrong going on here... Best Regards, Swung0x48 (aka. Huang Shiyuan) Get Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: Richard Henderson <richard.hender...@linaro.org> Sent: Wednesday, September 18, 2024 10:27:16 PM To: LIU Zhiwei <zhiwei_...@linux.alibaba.com>; qemu-devel@nongnu.org <qemu-devel@nongnu.org> Cc: qemu-ri...@nongnu.org <qemu-ri...@nongnu.org>; pal...@dabbelt.com <pal...@dabbelt.com>; alistair.fran...@wdc.com <alistair.fran...@wdc.com>; dbarb...@ventanamicro.com <dbarb...@ventanamicro.com>; liwei1...@gmail.com <liwei1...@gmail.com>; bmeng...@gmail.com <bmeng...@gmail.com>; Swung0x48 <swung0...@outlook.com>; TANG Tiancheng <tangtiancheng....@alibaba-inc.com> Subject: Re: [PATCH v4 02/12] tcg/riscv: Add basic support for vector On 9/18/24 12:43, LIU Zhiwei wrote: > > On 2024/9/18 18:11, Richard Henderson wrote: >> On 9/18/24 07:17, LIU Zhiwei wrote: >>> >>> On 2024/9/12 2:41, Richard Henderson wrote: >>>> On 9/11/24 06:26, LIU Zhiwei wrote: >>>>> From: Swung0x48<swung0...@outlook.com> >>>>> >>>>> The RISC-V vector instruction set utilizes the LMUL field to group >>>>> multiple registers, enabling variable-length vector registers. This >>>>> implementation uses only the first register number of each group while >>>>> reserving the other register numbers within the group. >>>>> >>>>> In TCG, each VEC_IR can have 3 types (TCG_TYPE_V64/128/256), and the >>>>> host runtime needs to adjust LMUL based on the type to use different >>>>> register groups. >>>>> >>>>> This presents challenges for TCG's register allocation. Currently, we >>>>> avoid modifying the register allocation part of TCG and only expose the >>>>> minimum number of vector registers. >>>>> >>>>> For example, when the host vlen is 64 bits and type is TCG_TYPE_V256, with >>>>> LMUL equal to 4, we use 4 vector registers as one register group. We can >>>>> use a maximum of 8 register groups, but the V0 register number is reserved >>>>> as a mask register, so we can effectively use at most 7 register groups. >>>>> Moreover, when type is smaller than TCG_TYPE_V256, only 7 registers are >>>>> forced to be used. This is because TCG cannot yet dynamically constrain >>>>> registers with type; likewise, when the host vlen is 128 bits and >>>>> TCG_TYPE_V256, we can use at most 15 registers. >>>>> >>>>> There is not much pressure on vector register allocation in TCG now, so >>>>> using 7 registers is feasible and will not have a major impact on code >>>>> generation. >>>>> >>>>> This patch: >>>>> 1. Reserves vector register 0 for use as a mask register. >>>>> 2. When using register groups, reserves the additional registers within >>>>> each group. >>>>> >>>>> Signed-off-by: TANG Tiancheng<tangtiancheng....@alibaba-inc.com> >>>>> Co-authored-by: TANG Tiancheng<tangtiancheng....@alibaba-inc.com> >>>> >>>> If there is a co-author, there should be another Signed-off-by. >>> >>> This patch has added a tag: >>> >>> Signed-off-by: TANG Tiancheng<tangtiancheng....@alibaba-inc.com> >>> >>> >>> Do you mean we should add the same tag twice? >> >> The from line is "Swung0x48 <swung0...@outlook.com>". >> If this is an alternate email for TANG Tiancheng, > > No, Swung0x48 is another author. Then we need a proper Signed-off-by line from that author. r~
