Page MenuHomePhabricator

huntergr (Graham Hunter)
User

Projects

User does not belong to any projects.

User Details

User Since
Sep 5 2014, 5:55 AM (259 w, 23 h)

Recent Activity

Wed, Aug 21

huntergr updated the diff for D66339: [SVE] Fixed-length vector MVT ranges.
  • Reordered MVTs to group fixed-length types together (and the same for scalable).
  • Replaced existing range accessors to remove explicit isScalableVector checks on MVTs in various backends.
Wed, Aug 21, 9:02 AM · Restricted Project

Fri, Aug 16

huntergr added a comment to D66339: [SVE] Fixed-length vector MVT ranges.

Split out from D53137.

Fri, Aug 16, 4:14 AM · Restricted Project
huntergr added a comment to D53137: Scalable vector core instruction support + size queries.

Created D66339 to split out the code to skip scalable vector types in other backends.

Fri, Aug 16, 4:14 AM · Restricted Project
huntergr created D66339: [SVE] Fixed-length vector MVT ranges.
Fri, Aug 16, 4:04 AM · Restricted Project

Fri, Aug 9

huntergr added a comment to D53137: Scalable vector core instruction support + size queries.

Thanks @huntergr for working on this!

This patch can probably be split into two separate patches, which make them easier to review;

  • One that fixes the Targets to ignore scalable types (see comment)
  • Another one that adds the interface for scalable size queries.
Fri, Aug 9, 3:34 AM · Restricted Project
huntergr added inline comments to D53137: Scalable vector core instruction support + size queries.
Fri, Aug 9, 3:16 AM · Restricted Project

Tue, Aug 6

huntergr updated the diff for D53137: Scalable vector core instruction support + size queries.
  • Added comments explaining the new methods
  • Added tests for the MVT/EVT/DataLayout interfaces
  • Refactored ScalableSize class operators to build on '==' and '<'
  • Added checks in various backends that don't support scalable vectors to prevent legalizing operations involving scalable MVTs
Tue, Aug 6, 5:55 AM · Restricted Project

Mon, Aug 5

huntergr committed rG208d63ea9018: [MVT][SVE] Map between scalable vector IR Type and VTs (authored by huntergr).
[MVT][SVE] Map between scalable vector IR Type and VTs
Mon, Aug 5, 4:19 AM
huntergr committed rL367832: [MVT][SVE] Map between scalable vector IR Type and VTs.
[MVT][SVE] Map between scalable vector IR Type and VTs
Mon, Aug 5, 4:18 AM
huntergr closed D47770: [MVT][SVE] Add EVT strings and Type mapping.
Mon, Aug 5, 4:18 AM · Restricted Project

Fri, Aug 2

huntergr updated the diff for D47770: [MVT][SVE] Add EVT strings and Type mapping.
  • Added inline comments to clarify boolean parameter meaning.
Fri, Aug 2, 3:29 AM · Restricted Project

Thu, Aug 1

huntergr added a comment to D53137: Scalable vector core instruction support + size queries.

Thanks for the reviews; I left a couple of inline comments, and will make the requested changes.

Thu, Aug 1, 6:22 AM · Restricted Project
huntergr added a reviewer for D47770: [MVT][SVE] Add EVT strings and Type mapping: rovka.
Thu, Aug 1, 5:09 AM · Restricted Project
huntergr updated the diff for D47770: [MVT][SVE] Add EVT strings and Type mapping.
  • Updated to head
  • Removed MVT-specific ElementCount in favour of using the common struct
  • Added unit tests.
Thu, Aug 1, 4:44 AM · Restricted Project

Wed, Jul 31

huntergr updated the diff for D53137: Scalable vector core instruction support + size queries.
  • Removed most of the changes in favour of reintroducing them in separate patches later with appropriate tests.
  • Added tests for core IR instructions to make sure they don't drop the scalable flag.
  • Fixed up a couple places which broke the new tests.
Wed, Jul 31, 4:04 AM · Restricted Project

Jul 23 2019

huntergr added a comment to D53137: Scalable vector core instruction support + size queries.

Hi Diana,

Jul 23 2019, 3:30 AM · Restricted Project

Jul 16 2019

huntergr updated the diff for D53137: Scalable vector core instruction support + size queries.

Updated based on where scalable size queries were required when running with an SVE-capable loop vectorizer on several codebases (all of LNT, various flavours of SpecCPU, lots of HPC and embedded benchmarks).

Jul 16 2019, 6:59 AM · Restricted Project

Jul 5 2019

huntergr committed rG957c40db6aeb: Scalable Vector IR Type with further LTO fixes (authored by huntergr).
Scalable Vector IR Type with further LTO fixes
Jul 5 2019, 5:49 AM
huntergr committed rL365203: Scalable Vector IR Type with further LTO fixes.
Scalable Vector IR Type with further LTO fixes
Jul 5 2019, 5:49 AM
huntergr closed D64079: Scalable Vector IR Type (Try 3).
Jul 5 2019, 5:48 AM · Restricted Project

Jul 2 2019

huntergr created D64079: Scalable Vector IR Type (Try 3).
Jul 2 2019, 7:11 AM · Restricted Project

Jun 18 2019

huntergr committed rG43854e3ccc7f: [SVE][IR] Scalable Vector IR Type with pr42210 fix (authored by huntergr).
[SVE][IR] Scalable Vector IR Type with pr42210 fix
Jun 18 2019, 3:11 AM
huntergr committed rL363658: [SVE][IR] Scalable Vector IR Type with pr42210 fix.
[SVE][IR] Scalable Vector IR Type with pr42210 fix
Jun 18 2019, 3:10 AM
huntergr closed D63321: [SVE][IR] Scalable Vector IR Type with pr42210 fix.
Jun 18 2019, 3:10 AM · Restricted Project

Jun 17 2019

huntergr added inline comments to D63321: [SVE][IR] Scalable Vector IR Type with pr42210 fix.
Jun 17 2019, 3:17 AM · Restricted Project

Jun 14 2019

huntergr created D63321: [SVE][IR] Scalable Vector IR Type with pr42210 fix.
Jun 14 2019, 12:58 AM · Restricted Project

Jun 10 2019

huntergr added a comment to D32530: [SVE][IR] Scalable Vector IR Type.

@huntergr do you have an account on bugzilla? I couldn't CC you on that bug.

Jun 10 2019, 2:29 AM · Restricted Project
huntergr added a comment to D32530: [SVE][IR] Scalable Vector IR Type.

Hi, this slowed down thinlto links 3-4x, and other things probably too. PR42210 has details. I've reverted this for now in r362913.

Jun 10 2019, 2:19 AM · Restricted Project

May 29 2019

huntergr committed rGf4fc01f8dd3a: [SVE][IR] Scalable Vector IR Type (authored by huntergr).
[SVE][IR] Scalable Vector IR Type
May 29 2019, 5:25 AM
huntergr committed rL361953: [SVE][IR] Scalable Vector IR Type.
[SVE][IR] Scalable Vector IR Type
May 29 2019, 5:20 AM
huntergr closed D32530: [SVE][IR] Scalable Vector IR Type.
May 29 2019, 5:20 AM · Restricted Project

May 28 2019

huntergr committed rG19e91253c0a5: [NFC] Test commit, delete trailing whitespace (authored by huntergr).
[NFC] Test commit, delete trailing whitespace
May 28 2019, 5:34 AM
huntergr committed rL361813: [NFC] Test commit, delete trailing whitespace.
[NFC] Test commit, delete trailing whitespace
May 28 2019, 5:34 AM

May 23 2019

huntergr updated the diff for D32530: [SVE][IR] Scalable Vector IR Type.
  • Simplified wording for extract/insertelement semantics
May 23 2019, 5:09 AM · Restricted Project

May 22 2019

huntergr updated the diff for D32530: [SVE][IR] Scalable Vector IR Type.
  • Changed textual IR format to <vscale x n x <ty>>
May 22 2019, 7:03 AM · Restricted Project

May 20 2019

huntergr added a comment to D32530: [SVE][IR] Scalable Vector IR Type.

It seems like there's enough support for changing to <vscale x as the prefix, so I'll revise the patch.

May 20 2019, 1:43 AM · Restricted Project

May 10 2019

huntergr updated the diff for D32530: [SVE][IR] Scalable Vector IR Type.
  • Changed (extract|insert)element semantics to return poison values at runtime if the index exceeds hardware vector length.
  • Changed shufflevector semantics to note that only zeroinitializer and undef can be used as mask values for scalable vectors for now.
May 10 2019, 12:05 AM · Restricted Project

May 2 2019

huntergr added a comment to D32530: [SVE][IR] Scalable Vector IR Type.

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
May 2 2019, 9:35 AM · Restricted Project
huntergr added a comment to D32530: [SVE][IR] Scalable Vector IR Type.

Sorry to be late to the party, but I have a quick question:

Ok, so do we have agreement that constant literal indices should be limited to 0..n-1 for now, but non-constant indices can potentially exceed n so that expressions featuring vscale can be used?

What if we know the width is fixed on our target machine? Let's say it's fixed at 512b. So a full width scalable double vector would be:

<vscale x 2 x double>

Since our width is fixed, we know that vscale=4 here and there are 8 elements in this vector.

I'd like to be able to do a really fast insert at say index 3. I.e. insert_element(<vscale x 2 x double> res, double elt, int 3). Would that insert be as fast with the vscale method as it would be for an index < n-1?

May 2 2019, 8:10 AM · Restricted Project

May 1 2019

huntergr added a comment to D32530: [SVE][IR] Scalable Vector IR Type.

Why implementation defined and not UB for the case where the index exceeds the runtime length? How do you intend to define this for SVE?

SVE uses a predicate for indexed inserts and extracts. We generate that predicate by comparing a splat of the index against a stepvector (0,1,2,3...); if the index is out of range then the predicate will be all false.

For a mov (insert), that results in an unmodified vector.

For a lastb (extract), that extracts the last lane in the vector if no predicate bits are true.

I don't know if RVV or SX-Aurora have similarly defined semantics. If the preference is to make it UB, that's fine.

I think this should be UB, or at least return poison. However, making it UB has the unfortunate side effect of making it illegal to hoist these operations out of conditionals (which currently isn't the case), so maybe poison is better.

For me the main reason for making is UB (aside from generally being conservative) is that element insert/extract can be usefully legalized by putting the vector into a stack slot and accessing the affected element with scalar loads/stores -- in fact, that's the default legalization strategy in trunk. But in that setting an out-of-bounds lane index would become a wild read/write (= clear-cut UB), unless the legalization code jumps through extra hoops to add a bounds check or clamp the lane index into range. This wouldn't affect SVE or RVV since they would implement custom lowering anyway, but for other targets (especially if we eventually generalize insert/extract to accept variable lane positions and do so for all vector types for consistency) it could become an unnecessary headache. Though if we make insertelement with out-of-range lane index return poison instead of being UB, then at minimum clamping in insertelement is necessary to avoid the wild write.

Aside: your proposed semantics for SVE would break the property extractelt(insertelt(vec, i, elt), i) = elt which instcombine (and others) most likely assumes. If we make the insertelt return poison (or even just undef, FWIW), that issue goes away.

I think that making the return be a poison value is best.

May 1 2019, 6:45 AM · Restricted Project
huntergr added a comment to D32530: [SVE][IR] Scalable Vector IR Type.

Noted the change in semantics for extractelement and insertelement in the langref.

Why implementation defined and not UB for the case where the index exceeds the runtime length? How do you intend to define this for SVE?

May 1 2019, 2:25 AM · Restricted Project

Apr 30 2019

huntergr updated the diff for D32530: [SVE][IR] Scalable Vector IR Type.

Noted the change in semantics for extractelement and insertelement in the langref.

Apr 30 2019, 5:11 AM · Restricted Project

Apr 25 2019

huntergr added a comment to D32530: [SVE][IR] Scalable Vector IR Type.

Exactly. Non-constant values can become constant. Constant values can be guarded by vscale-dependent runtime guards (both hand-written and compiler generated). My preference is to leave this not restricted to vscale == 1 values, but rather allow all values that can be supported at runtime, and have it be UB if, at runtime, the relevant index is not available.

+1

That means a need for a warning to general developers: If there is a check for constant_index >= n to see if the result is a poison value, that code has to be changed so that it applies to non-scalable vector only. Hopefully not too many instances of that. I'm fine with this as long as the communication to the rest of LLVM community is clear about it.

Apr 25 2019, 6:14 AM · Restricted Project

Apr 23 2019

huntergr added a comment to D32530: [SVE][IR] Scalable Vector IR Type.

I am not sure how it could be anything but n. If you don't know how long the vector is, you can't correctly generate an index beyond n.

But you know at runtime... there has to be a way to determine, at runtime, vscale. And the index doesn't need to be a constant. I'm not sure that we need to restrict non-constant n to only values valid for vscale == 1.

Good point. 100% agree. I was only considering the constant case.

Apr 23 2019, 5:50 AM · Restricted Project

Apr 18 2019

huntergr added a comment to D32530: [SVE][IR] Scalable Vector IR Type.

We need to clarify on insertelement/extractelement. Maybe already done in some other patches, but that clarification should be part of this patch.
Is the "length of val" under the semantics "scalable * n" in <scalable n x ElemTy>, right? Or is it still n?

I am not sure how it could be anything but n. If you don't know how long the vector is, you can't correctly generate an index beyond n.

But you know at runtime... there has to be a way to determine, at runtime, vscale. And the index doesn't need to be a constant. I'm not sure that we need to restrict non-constant n to only values valid for vscale == 1.

Apr 18 2019, 2:54 AM · Restricted Project
huntergr added inline comments to D32530: [SVE][IR] Scalable Vector IR Type.
Apr 18 2019, 2:46 AM · Restricted Project
huntergr added a comment to D32530: [SVE][IR] Scalable Vector IR Type.

We need to clarify on insertelement/extractelement. Maybe already done in some other patches, but that clarification should be part of this patch.
Is the "length of val" under the semantics "scalable * n" in <scalable n x ElemTy>, right? Or is it still n?

I am not sure how it could be anything but n. If you don't know how long the vector is, you can't correctly generate an index beyond n. I assume for vectors of length > n one would have to use shufflevector or something similar (using vscale and stepvector as Graham mentioned) to get the elements you want to the lower n positions.

Either way, the semantics and any restrictions certainly need to be documented.

Apr 18 2019, 2:38 AM · Restricted Project
huntergr added a comment to D32530: [SVE][IR] Scalable Vector IR Type.

That's pretty much what LLVM-VP is about: https://reviews.llvm.org/D57504

We are proposing compress/expand and lane shift as intrinsics.
I suggest you add any shuffle intrinsics to the same namespace to avoid fragmentation.

Apr 18 2019, 2:38 AM · Restricted Project

Apr 15 2019

huntergr added a comment to D32530: [SVE][IR] Scalable Vector IR Type.

I think this is a coherent set of changes. Given the current top of trunk, this expands support from just assembly/disassembly of machine instructions to include LLVM IR, right? Such being the case, I think this patch should go in. I have some ideas on how to structure passes so SV IR supporting optimizations can be added incrementally. If anyone thinks such a proposal would help, let me know.

I think there is one more thing we still have to do. Does scalable vector type apply to all Instructions where non-scalable vector is allowed? If the answer is no, we need to identify which ones are not allowed to take scalable vector type operand/result. Some of the Instructions are not plain element-wise operation. Do we have agreed upon semantics for all those that are allowed?

Apr 15 2019, 6:46 AM · Restricted Project

Apr 9 2019

huntergr added inline comments to D32530: [SVE][IR] Scalable Vector IR Type.
Apr 9 2019, 5:57 AM · Restricted Project
huntergr added inline comments to D32530: [SVE][IR] Scalable Vector IR Type.
Apr 9 2019, 12:48 AM · Restricted Project

Apr 5 2019

huntergr updated the diff for D32530: [SVE][IR] Scalable Vector IR Type.
  • Clarified that the runtime multiple is constant across all scalable vector types, even if the constant value isn't known at compile time.
  • Removed extra whitespace.
Apr 5 2019, 5:48 AM · Restricted Project
huntergr added inline comments to D32530: [SVE][IR] Scalable Vector IR Type.
Apr 5 2019, 2:45 AM · Restricted Project
huntergr added a comment to D32530: [SVE][IR] Scalable Vector IR Type.

I think this patch is a good start and I don't mind having it merged as is, I was just suggesting a way forward since it seems people are still hesitating. While there seems to be some consensus on moving forward with native types, I'm sure many of the details are still somewhat fuzzy. In my opinion having more patches reviewed would make those details clear, and it would thus make it easier to get more sign-offs on this patch as well.

Apr 5 2019, 2:36 AM · Restricted Project
huntergr added a comment to D32530: [SVE][IR] Scalable Vector IR Type.

I'd advise caution here, it's really significant/impactful change, and a single sign-off is a bit worrying.
In particular, even regardless of the feature itself, has the implementation itself been reviewed?

Apr 5 2019, 2:28 AM · Restricted Project

Apr 2 2019

huntergr added a comment to D32530: [SVE][IR] Scalable Vector IR Type.

I am accepting the scalable vector types based on the comments in
http://lists.llvm.org/pipermail/llvm-dev/2019-March/131137.html

Let's move forward with SVE support in LLVM. Thanks!

Apr 2 2019, 8:12 AM · Restricted Project
huntergr abandoned D31417: [OpenMP] Add support for omp simd pragmas without runtime.

LGTM. This provides a consistent behavior same as GCC and ICC w/ -fopenmp-simd option. To answer, Kelvin's question. it is not directly tied with "target".

Apr 2 2019, 1:44 AM

Mar 22 2019

huntergr planned changes to D53137: Scalable vector core instruction support + size queries.
Mar 22 2019, 3:07 AM · Restricted Project
huntergr abandoned D47780: [AArch64][SVE] Testing codegen of scalable vectorized loop.

A more focused set of unit tests will be created instead of this demonstration test.

Mar 22 2019, 3:05 AM
huntergr planned changes to D47779: [AArch64][SVE] Implement copying for Z registers.
Mar 22 2019, 3:05 AM
huntergr abandoned D47778: [AArch64][SVE] Left shift patterns for scalable integer types.

A better set of patterns will be created later.

Mar 22 2019, 3:05 AM
huntergr abandoned D47776: [AArch64][SVE] Initial store patterns for SVE.

A better set of patterns will be created later.

Mar 22 2019, 3:05 AM
huntergr abandoned D47777: [AArch64][SVE] Addition patterns for integer scalable vectors.

A better set of patterns will be created later.

Mar 22 2019, 3:05 AM
huntergr planned changes to D47775: [AArch64][SVE] Add SplatVector Intrinsic.

Needs to be updated with better isel patterns (and possibly a new ISD?), instead of just the bare minimum required for demonstration.

Mar 22 2019, 3:05 AM
huntergr planned changes to D47773: [AArch64][SVE] Add VScale Intrinsic.

Needs to be updated with better isel patterns, instead of just the bare minimum required for demonstration.

Mar 22 2019, 3:01 AM
huntergr planned changes to D47774: [AArch64][SVE] Add StepVector Intrinsic.

Needs to be updated with better isel patterns, instead of just the bare minimum required for demonstration.

Mar 22 2019, 3:01 AM

Mar 21 2019

huntergr updated the diff for D32530: [SVE][IR] Scalable Vector IR Type.

Rebased, incorporated fixes from reviews.

Mar 21 2019, 10:20 AM · Restricted Project

Mar 15 2019

huntergr abandoned D59245: SVE opaque type for C intrinsics demo.
Mar 15 2019, 9:58 AM
huntergr abandoned D59246: SVE opaque type for C intrinsics demo (LLVM side).
Mar 15 2019, 9:58 AM

Mar 12 2019

huntergr created D59246: SVE opaque type for C intrinsics demo (LLVM side).
Mar 12 2019, 4:26 AM
huntergr created D59245: SVE opaque type for C intrinsics demo.
Mar 12 2019, 4:23 AM

Jan 30 2019

huntergr updated the diff for D53695: Scalable VectorType RFC.

Update based on off-list feedback:

  • Added a section on allowed operations to clarify this is a first class type.
  • Remove initial proposal on the flag for not inheriting vlen; there's more pushback against allowing runtime multiple changes. I think this design could still be extended to support that in the future, but I'm afraid I'll have to leave that battle to the RVV team.
  • Minor wording changes.
Jan 30 2019, 3:22 AM

Nov 2 2018

huntergr updated the diff for D53137: Scalable vector core instruction support + size queries.
  • Unified ScalableSize representation
  • Changed to uint64_t + boolean, since we no longer allow scalable vectors in aggregates
  • Removed aggregate and mixed unit tests
Nov 2 2018, 5:27 PM · Restricted Project
huntergr updated the diff for D32530: [SVE][IR] Scalable Vector IR Type.
  • Added checks in verifier to prevent scalable vectors being included in structs or arrays
  • Changed lookup to use ElementCount
  • Moved ElementCount to a new file
  • More unit tests
Nov 2 2018, 5:21 PM · Restricted Project
huntergr updated the diff for D53695: Scalable VectorType RFC.

Updated based on feedback:

  • Add reasons for restrictions on global/aggregates
  • Change size query struct to an integer + a boolean instead of two integers.
Nov 2 2018, 4:35 PM

Oct 31 2018

huntergr added a comment to D53695: Scalable VectorType RFC.

Also, can you move this to docs/Proposals, together with the other RFCs, please?

Oct 31 2018, 6:29 AM

Oct 25 2018

huntergr updated the diff for D53695: Scalable VectorType RFC.

Updated based on discussions at the 2018 devmeeting

Oct 25 2018, 5:57 AM
huntergr created D53695: Scalable VectorType RFC.
Oct 25 2018, 5:56 AM

Oct 24 2018

huntergr abandoned D53138: Scalable type size queries (clang).

Abandoning this. At the devmeeting it was agreed that 'getPrimitiveSizeInBits' should continue to work as-is for fixed-length vectors and only behave differently for scalable vectors.

Oct 24 2018, 4:16 AM

Oct 11 2018

huntergr added a parent revision for D53137: Scalable vector core instruction support + size queries: D32530: [SVE][IR] Scalable Vector IR Type.
Oct 11 2018, 7:03 AM · Restricted Project
huntergr added a child revision for D32530: [SVE][IR] Scalable Vector IR Type: D53137: Scalable vector core instruction support + size queries.
Oct 11 2018, 7:03 AM · Restricted Project
huntergr added a parent revision for D53138: Scalable type size queries (clang): D53137: Scalable vector core instruction support + size queries.
Oct 11 2018, 7:03 AM
huntergr added a child revision for D53137: Scalable vector core instruction support + size queries: D53138: Scalable type size queries (clang).
Oct 11 2018, 7:03 AM · Restricted Project
huntergr created D53138: Scalable type size queries (clang).
Oct 11 2018, 7:02 AM
huntergr created D53137: Scalable vector core instruction support + size queries.
Oct 11 2018, 6:59 AM · Restricted Project

Sep 4 2018

huntergr added inline comments to D32530: [SVE][IR] Scalable Vector IR Type.
Sep 4 2018, 2:39 AM · Restricted Project

Aug 1 2018

huntergr updated the summary of D47771: [AArch64][SVE] Scalable arguments and returns passed in Z regs.
Aug 1 2018, 6:58 AM

Jul 26 2018

huntergr added inline comments to D32530: [SVE][IR] Scalable Vector IR Type.
Jul 26 2018, 4:55 AM · Restricted Project

Jul 19 2018

huntergr added inline comments to D32530: [SVE][IR] Scalable Vector IR Type.
Jul 19 2018, 8:01 AM · Restricted Project
huntergr added reviewers for D32530: [SVE][IR] Scalable Vector IR Type: samparker, SjoerdMeijer.
Jul 19 2018, 7:47 AM · Restricted Project

Jul 16 2018

huntergr updated the diff for D32530: [SVE][IR] Scalable Vector IR Type.

Indeed, we shouldn't allow scalable vectors to be globals. I've added a check for that in the verifier, plus unit tests and a small update to the langref. Thanks.

Jul 16 2018, 3:24 AM · Restricted Project

Jul 12 2018

huntergr added a reviewer for D32530: [SVE][IR] Scalable Vector IR Type: rkruppe.

I think the discussion on the mailing list has reached agreement on this type being suitable for both SVE and RVV; any review comments on the code or tests?

Jul 12 2018, 3:11 AM · Restricted Project

Jun 7 2018

huntergr updated the diff for D47770: [MVT][SVE] Add EVT strings and Type mapping.

Fixed string representation of scalable vectors which don't map to the existing defined set of MVTs.

Jun 7 2018, 5:34 AM · Restricted Project

Jun 6 2018

huntergr updated the diff for D47780: [AArch64][SVE] Testing codegen of scalable vectorized loop.

Removed unnecessary metadata.

Jun 6 2018, 7:06 AM

Jun 5 2018

huntergr updated subscribers of D47780: [AArch64][SVE] Testing codegen of scalable vectorized loop.
Jun 5 2018, 7:57 AM
huntergr updated subscribers of D47779: [AArch64][SVE] Implement copying for Z registers.
Jun 5 2018, 7:54 AM
huntergr updated subscribers of D47778: [AArch64][SVE] Left shift patterns for scalable integer types.
Jun 5 2018, 7:53 AM
huntergr updated subscribers of D47777: [AArch64][SVE] Addition patterns for integer scalable vectors.
Jun 5 2018, 7:53 AM
huntergr updated subscribers of D47776: [AArch64][SVE] Initial store patterns for SVE.
Jun 5 2018, 7:53 AM
huntergr updated subscribers of D47775: [AArch64][SVE] Add SplatVector Intrinsic.
Jun 5 2018, 7:53 AM