[llvm-dev] [RFC] Supporting ARM's SVE in LLVM

[Renato Golin via llvm-dev]

On 28 November 2016 at 15:37, Paul Walker <Paul.Walker at arm.com> wrote:
> (1)     seriesvector(i32 0, i32 2)
> (2)     mul(seriesvector(i32 0, i32,1), splat(2))
>
> Both patterns are likely to occur and so must be matched within InstCombine and friends.  The solution could be to first simplify seriesvector related IR to a canonical form so only a single pattern requires matching against.  The "stepvector" proposal asks why we would bother introducing the problem in the first place and instead force a canonical representation from the outset.
>
> Obviously there will exist new idioms to canonicalise ((2*stepvector) + stepvector <==> 3*stepvector) but at least the most common cases are handled automatically.

I guess this is true for all constants, and it falls to things like
constant folding to bring it to a canonical representation.


> We made this change when creating the upstream patch for "seriesvector" and observed its effect on the code base.  When switching to "stepvector" the resulting patch was about 1/5 the size.  That said if a constant intrinsic is the way to go then I imagine said patch will be even smaller.

If we use an intrinsic, we'll need to add this special case to the
vectoriser and maybe other passes, to treat that as a constant, but it
will be an addition, not a replacement.

If we create a new constant type, we'll need to change *a lot* of
existing tests (providing we want to use it across the board), which
will be a more complex change overall.

I'd leave that for later, once we have settled the semantics between
SVE and RISC-V, and just have an intrinsic for now. Once RISC-V
implementation comes, we can compare it to SVE, and if it's identical,
it'll be easier to implement as an intrinsic (for quick enablement),
then later on, it'll be a no-brainer refactory.

But this is just my personal (and reasonably uninformed) opinion. I'll
let other people broaden the discussion a bit. :)

cheers,
--renato