[PATCH] D27105: [Constants] Add "stepvector" to represent the sequence 0, 1, 2, 3... [IR support for SVE scalable vectors 4/4]

Renato Golin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Nov 30 06:07:18 PST 2016


rengolin added a comment.

Right, this is the one I'm still unsure about. What is the value of having a whole new construct to build `<0, 1, 2, ..., n-1>`?

I mean, if the new construct was generic enough to represent all possible sequences (reverse, step, multiplicative, etc), then it would be a change that is guaranteed to extend to all future usages. This one is so restricted that we'll have to change again in the near future to add more functionality.

Of course, we could use this construct to build the sequences in IR. Examples:

  for (0..N-1) { a[i] = i; }

would increment `i` (as `%index`) like:

  %a = PHI (getelementptr, %new.a)
  %index = i32 0
  ...
  ; create a step vector <0, 1, ... N>
  %step = constant <n x 4 x i32> stepvector
  ; create a splat vector with the start of the sequence
  %curidx = insertelement <n x 4 x i32> undef, i32 %index, i32 0
  %curidx.1 = shufflevector <n x 4 x i32> %a, <n x 4 x i32> undef, <n x 4 x i32> zeroinitializer
  ; add them together to get the current sequence
  %ind = add <n x 4 x i32> %step, <n x 4 x i32> curidx.1
  ; store the sequence into a[i]
  store <n x 4 x i32> ind, i32* %a
  ; update the index/address
  %index = add i32 %index, i32 vscale
  %new.a = toptr( add toint(i32* %a), mul(i32 vscale, i32 4) )

If we had an intrinsic for this, we'd be able to have any scalar evolution. Example:

  @llvm.scalable_vector.step(i32 %start, i32 %a, i32 %b) ; as %start + (%a * x + %b)

The above loop would be:

  
  %a = PHI (getelementptr, %new.a)
  %index = i32 0
  ...
  ; create a step vector <0, 1, ... N>
  %step = @llvm.scalable_vector.step.4.i32(i32 %index, i32 1, i32 1)
  ; store the sequence into a[i]
  store <n x 4 x i32> ind, i32* %step
  ; update the index/address
  %index = add i32 %index, i32 vscale
  %new.a = toptr( add toint(i32* %a), mul(i32 vscale, i32 4) )

And this would work for all possible induction evolutions: positive, negative, multiples, etc.

Maybe going with ax+b is a bit too far, but certainly a constant step (plus/minus) and a starting point would be a great advantage to the notation, and it wouldn't (for now), change the IR to introduce a concept that is far too localised to be worth breaking compatibility.

Hope this makes sense...

cheers,
--renato


https://reviews.llvm.org/D27105





More information about the llvm-commits mailing list