[llvm-dev] Questions about vscale

[Hanna Kruppe via llvm-dev]

On Wed, 8 Apr 2020 at 05:23, Kai Wang <kai.wang at sifive.com> wrote:
>
> [snip]
>
> If we apply the type system pointed out by Renato, is the vector type <vscale x 1 x i16> legal? If we decide that <vscale x 1 x i16> is a fundamentally impossible type, does it contrary to the philosophy of LLVM IR as reasonably target-independent IR? I do not get the point of your argument.
>

<vscale x 1 x i16> would be illegal, but like other illegal types, it
can be legalized. It does not run into the problem I see with
fractional vscale, since the number of elements each vector type is
supposed to have is still a whole number. For example, it could be
legalized by using a full vector register as for <vscale x 1 x i32>
and sign-extending or zero-extending each element as needed by the
operations performed on it. Another possibility is using a full vector
register with SEW=16, but computing `vl` as for SEW=32 which
effectively means using only the lower half of the vector register.
Both options always ensure we correctly (if slowly) emulate a vector
containing as many i16 elements as <vscale x 1 x i32> has i32
elements.

To be clear: in LLVM jargon, a type being "illegal" does not mean that
the type is not supposed to be used. It only means that the type isn't
directly supported by the hardware, but can be mapped to the things
the hardware does support with extra effort and at the expense of some
performance. For example, i64 is illegal on typical 32 bit targets,
but clang happily uses i64 for C types like `long` or `long long`
(depending on ABI), and backends support this. Another example are the
float and double types on any target without FPU (including RISC-V
without F/D extension).

I hope this clarifies the distinction I made before.

Kind regards,
Hanna

PS: I'm ignoring the "fractional LMUL" proposal in this discussion, I
hope that's okay for you. If it was adopted it would give us a larger
set of legal types, but all the concepts we're discussing here would
still apply to other types, so let's stick with LMUL > 1 to avoid
confusion.

>>
>>
>> The obvious solution is to use a different set of legal vector types
>> (and thus, a different interpretation of vscale) depending on the
>> largest legal element type (ELEN in RISC-V jargon). This corresponds
>> to the table for ELEN=32 that Renato gave above. Kai's proposal is
>> intended to avoid this, and I can understand the desire for that, but
>> it really seems like the lesser evil to me.
>
>
> The problem of defining a different type system depending on the largest legal element type (ELEN in RISC-V jargon) is that they are not compatible. I assume that programs compiled under ELEN = 32 could be run on ELEN = 64 machines. It should be possible to link ELEN = 32 objects with ELEN = 64 objects. If we use the type <vscale x 1 x i32> under ELEN = 32, there is no corresponding type under ELEN = 64 for <vscale x 1 x i32> (look up in my table). It seems an illegal type under ELEN = 64. Does it follow the philosophy of target independent IR?
>
> I hope we could design an unified type system for different ELEN. However, the vscale may be fractional on run time under some circumstances (VLEN = 32, ELEN = 32) in my proposal. That is why I wonder to know whether the fractional vscale is matter or not.
>
> Thanks,
> Kai
>
>>
>> Best regards
>> Hanna
>>
>>
>> > > Is there any problem to assume vscale to be fractional under some circumstances? vscale should be an unknown value when compiling. So, it should have no impact on code generation and optimization. The relationship between types is correct regardless vscale’s value. Is there anything I missed?
>> >
>> > I believe the assumption was always that vscale is an integer.
>> > Representing it as a fraction would need code change for sure, but
>> > also reevaluate the assumptions.
>> >
>> > I'm copying some SVE and LV people to give a more informed opinion.
>> >
>> > cheers,
>> > --renato
>> > _______________________________________________
>> > LLVM Developers mailing list
>> > llvm-dev at lists.llvm.org
>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev