[PATCH] D32530: [SVE][IR] Scalable Vector IR Type

Cameron McInally via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu May 2 09:02:46 PDT 2019


cameron.mcinally added a comment.

> If you know the exact size of your vectors at compile time, then I believe fixed length vector types should be used, at least at the IR level.

Ah, ok. So let's say we're targeting SVE and I know my vector length is 512b. I was imagining building a vector like this:

  %r1 = insertelement <scalable 2 x double> undef, double %x, i32 0  
  %r2 = insertelement <scalable 2 x double > %r1, double %x1, i32 1
  %r3 = insertelement <scalable 2 x double > %r2, double %x2, i32 2
  %r4 = insertelement <scalable 2 x double > %r3, double %x3, i32 3
  %r5 = insertelement <scalable 2 x double > %r4, double %x4, i32 4
  %r6 = insertelement <scalable 2 x double > %r5, double %x5, i32 5
  %r7 = insertelement <scalable 2 x double > %r6, double %x6, i32 6
  %r8 = insertelement <scalable 2 x double > %r7, double %x7, i32 7

But it sounds like I should rather just build a <8 x double> vector instead. Would that <8 x double> vector legalize to SVE vector instructions? Or would it be split into four 128b NEON vectors?

> The performance of insert/extract is target dependent. For SVE you almost always need a predicate for a single element insert or extract, so you're not going to gain anything by knowing the size ahead of time.

So back to my scalable vector example above, it sounds like even if the above IR was valid, we'd still have to produce predicates at the hardware instruction level. So maybe my concern is moot...


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D32530/new/

https://reviews.llvm.org/D32530





More information about the llvm-commits mailing list