[llvm-dev] Questions about vscale

[Kai Wang via llvm-dev]

Hi Renato,

Thanks for your explanation. It is very helpful. Now I totally understand
your concern.

In GCC, it has a similar representation for scalable vector type. It uses a
data structure called poly-int[1] to represent the run-time part. It also
used to represent the relationship(half size, double size, etc.) between
types. It looks similar to (a * X + b) * type. X represents the run-time
value. It is equivalent to LLVM representation using vscale * n * type.

Similarly, there is a target hook to calculate (a * X + b) in GCC, called
TARGET_ESTIMATED_POLY_VALUE[2]. The difference between GCC and LLVM is that
GCC uses whole polynomial expression to calculate the actual run-time
vector length instead of getting the run-time variable only, i.e., X in GCC
and vscale in LLVM. Maybe it is not a good idea to return float for vscale
intrinsic. It should be more reasonable to take the element count into the
intrinsic to calculate the actual run-time length for scalable vector
types. That is,

declare i32 llvm.vscale.i32(i32 ElementCount)
declare i64 llvm.vscale.i64(i32 ElementCount)

Does it make sense?

[1]
https://gcc.gnu.org/onlinedocs/gccint/Overview-of-poly_005fint.html#Overview-of-poly_005fint
[2] https://github.com/gcc-mirror/gcc/blob/master/gcc/targhooks.c#L1703

On Sat, Apr 11, 2020 at 11:32 PM Renato Golin <rengolin at gmail.com> wrote:

> Hi Kai,
>
> On Sat, 11 Apr 2020 at 15:55, Kai Wang <kai.wang at sifive.com> wrote:
> > IIUC. If I could lower LLVM IR to Asm correctly under my type system
> design, there should be no problem with it.
>
> It depends on what you mean by "no problem". :)
>
> The design of the IR is target independent, so that we can represent
> language constructs in a generic way and optimise them with a common
> infrastructure.
>
> However, there are three main sources of target-dependence:
>
> 1. Front-ends may lower different IR depending on different targets,
> for example valid types, call ABI, etc.
> 2. The middle-end takes decisions based on target validity, which
> changes the shape of IR, for example specific sequences of
> instructions on specific types.
> 3. Intrinsic functions. Those can be generated by the front-end or a
> pass optimises code with them, for example, the vectoriser.
>
> The general trend is that the IR becomes more target-dependent as more
> passes change it, but it also means passes are less and less able to
> recognise patterns and therefore are less useful on your code. That's
> why pass ordering matters.
>
> A good example is GPU/accelerator code, that if you pass the IR
> through the normal pipeline, it comes out the other way unrecognisable
> and impossible to lower, so they tend to have their own pass
> pipelines.
>
> You don't want to have a special, so you need to make sure your IR is
> as generic as possible, or you won't profit as much, or worse, will
> break apart.
>
> More specifically, the entirety of vscale design has been assuming
> integral scales, so anything that is not integral will very likely not
> work with existing (and future) standard passes.
>
> By making your target more special, you have also made it harder to
> optimise. Neither you nor the rest of the community wants to add
> special cases for odd targets in every optimisation pass, so we need
> to find a common ground.
>
> > Another concern I have is that llvm.vscale intrinsic is designed to
> return integer value. Should we relax it to return float or something else?
>
> I personally believe that this would open a can of worms we don't want
> to handle. Not right now, at the very least.
>
> I would strongly oppose to a float value, for all of the problems FP
> representation has and the expectation of existing instructions of
> taking integer values.
>
> But it could be doable to have a fractional value, like two integers,
> where the numerator doesn't have to be greater than nor a multiple of
> the denominator (with default value as 1).
>
> Again, I'm not the authority here, I'm just giving some context. Other
> scalable vector developers should chime in with their opinion.
>
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200413/a04d843d/attachment.html>