[llvm-dev] Questions about vscale

[Renato Golin via llvm-dev]

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