Page MenuHomePhabricator

gilr (Gil Rapaport)
User

Projects

User does not belong to any projects.

User Details

User Since
Nov 12 2014, 11:00 PM (310 w, 1 h)

Recent Activity

Jul 8 2020

gilr added inline comments to D75069: [LoopVectorizer] Inloop vector reductions.
Jul 8 2020, 6:42 AM · Restricted Project

Jun 16 2020

gilr accepted D80220: [VPlan] Add & use VPValue for VPWidenGEPRecipe operands (NFC)..

We still use GEP->clone() for the case where the GEP is loop invariant. It would probably be best to do that in a follow-on patch. Same for perhaps storing InBounds directly in the recipe as well.

Jun 16 2020, 2:43 AM · Restricted Project

Jun 6 2020

gilr added a comment to D80220: [VPlan] Add & use VPValue for VPWidenGEPRecipe operands (NFC)..

The patch LGTM, any reason not to include the base pointer?

Jun 6 2020, 11:12 AM · Restricted Project

May 24 2020

gilr accepted D80219: [VPlan] Use VPUser for VPWidenSelectRecipe operands (NFC)..
May 24 2020, 1:02 AM · Restricted Project

May 18 2020

gilr accepted D80114: [VPlan] Add & use VPValue operands for VPReplicateRecipe (NFC)..

LGTM with a nit. Thanks!

May 18 2020, 8:01 AM · Restricted Project

May 10 2020

gilr accepted D78883: [VPlan] Move emission of \\l\"+\n to dumpBasicBlock (NFC)..

Thanks for looking into this, Florian (and sorry for taking so long).
LGTM, except VPInterleaveRecipe::print() is missing here.
The patch stands by itself as a standardization of printing, similar to how the multi-line Function and Module print. If meant as a first step, would be good to elaborate on the full picture.

May 10 2020, 12:29 AM · Restricted Project

Apr 22 2020

gilr accepted D76992: [VPlan] Add & use VPValue operands for VPWidenRecipe (NFC)..

LGTM (with that missing comment nit), thanks!

Apr 22 2020, 8:06 AM · Restricted Project
gilr added inline comments to D76992: [VPlan] Add & use VPValue operands for VPWidenRecipe (NFC)..
Apr 22 2020, 4:49 AM · Restricted Project
gilr added inline comments to D76992: [VPlan] Add & use VPValue operands for VPWidenRecipe (NFC)..
Apr 22 2020, 4:17 AM · Restricted Project
gilr added inline comments to D76992: [VPlan] Add & use VPValue operands for VPWidenRecipe (NFC)..
Apr 22 2020, 3:44 AM · Restricted Project

Apr 19 2020

gilr accepted D78288: [VPlan] Make various tryTo* helpers private and mark as const (NFC)..

LGTM, thanks.

Apr 19 2020, 3:11 AM · Restricted Project

Apr 15 2020

gilr committed rGb747d72c1971: [LV] Fix PR45525: Incorrect assert in blend recipe (authored by gilr).
[LV] Fix PR45525: Incorrect assert in blend recipe
Apr 15 2020, 1:03 AM
gilr closed D78115: [LV] Fix PR45525: Incorrect assert in blend recipe.
Apr 15 2020, 1:03 AM · Restricted Project
gilr updated the diff for D78115: [LV] Fix PR45525: Incorrect assert in blend recipe.

Addressed comments and narrowed LIT checks to the relevant vectorized instructions.
Thanks @fhahn !

Apr 15 2020, 12:30 AM · Restricted Project

Apr 14 2020

gilr created D78115: [LV] Fix PR45525: Incorrect assert in blend recipe.
Apr 14 2020, 8:33 AM · Restricted Project

Apr 13 2020

gilr committed rG41ed5d856c1b: [LV] Clean up vectorizeInterleaveGroup (NFCI) (authored by gilr).
[LV] Clean up vectorizeInterleaveGroup (NFCI)
Apr 13 2020, 3:44 AM
gilr closed D78002: [LV] Clean up vectorizeInterleaveGroup (NFCI).
Apr 13 2020, 3:44 AM · Restricted Project

Apr 12 2020

gilr created D78002: [LV] Clean up vectorizeInterleaveGroup (NFCI).
Apr 12 2020, 11:01 PM · Restricted Project
gilr accepted D77869: [VPlan] Introduce VPWidenSelectRecipe (NFC)..

LGTM, thanks!

Apr 12 2020, 9:04 AM · Restricted Project
gilr added inline comments to D77869: [VPlan] Introduce VPWidenSelectRecipe (NFC)..
Apr 12 2020, 6:23 AM · Restricted Project
gilr added inline comments to D77869: [VPlan] Introduce VPWidenSelectRecipe (NFC)..
Apr 12 2020, 2:39 AM · Restricted Project

Apr 10 2020

gilr added inline comments to D76992: [VPlan] Add & use VPValue operands for VPWidenRecipe (NFC)..
Apr 10 2020, 2:08 AM · Restricted Project

Apr 9 2020

gilr added inline comments to D76992: [VPlan] Add & use VPValue operands for VPWidenRecipe (NFC)..
Apr 9 2020, 1:28 PM · Restricted Project
gilr committed rGe2a186788051: [LV] Add VPValue operands to VPBlendRecipe (NFCI) (authored by gilr).
[LV] Add VPValue operands to VPBlendRecipe (NFCI)
Apr 9 2020, 1:11 PM
gilr closed D77539: [LV] Add VPValue operands to VPBlendRecipe (NFCI).
Apr 9 2020, 1:11 PM · Restricted Project

Apr 8 2020

gilr accepted D77655: [VPlan] Add & use VPValue operands for VPWidenCallRecipe (NFC)..
Apr 8 2020, 2:41 PM · Restricted Project
gilr updated the diff for D77539: [LV] Add VPValue operands to VPBlendRecipe (NFCI).

Addressed comments.

Apr 8 2020, 7:02 AM · Restricted Project
gilr added inline comments to D77655: [VPlan] Add & use VPValue operands for VPWidenCallRecipe (NFC)..
Apr 8 2020, 4:49 AM · Restricted Project

Apr 7 2020

gilr updated the diff for D77539: [LV] Add VPValue operands to VPBlendRecipe (NFCI).

Address comments

Apr 7 2020, 10:18 AM · Restricted Project

Apr 6 2020

gilr created D77539: [LV] Add VPValue operands to VPBlendRecipe (NFCI).
Apr 6 2020, 4:17 AM · Restricted Project

Apr 5 2020

gilr accepted D77467: [VPlan] Introduce new VPWidenCallRecipe (NFC)..

LGTM, thanks!

Apr 5 2020, 7:59 AM · Restricted Project

Apr 4 2020

gilr added inline comments to D77467: [VPlan] Introduce new VPWidenCallRecipe (NFC)..
Apr 4 2020, 12:45 PM · Restricted Project

Mar 28 2020

gilr accepted D76988: [VPlan] Use on VPWidenRecipe per original IR instruction. (NFC)..

LGTM, with a nit.

Mar 28 2020, 11:04 PM · Restricted Project
gilr added inline comments to D76988: [VPlan] Use on VPWidenRecipe per original IR instruction. (NFC)..
Mar 28 2020, 10:44 AM · Restricted Project

Mar 25 2020

gilr committed rG078c8633055b: [LV] Replace stored value with a VPValue (NFCI) (authored by gilr).
[LV] Replace stored value with a VPValue (NFCI)
Mar 25 2020, 10:48 AM
gilr closed D76373: [LV] Replace stored value with a VPValue (NFCI).
Mar 25 2020, 10:48 AM · Restricted Project
gilr updated the diff for D76373: [LV] Replace stored value with a VPValue (NFCI).

Addressed comments.

Mar 25 2020, 1:03 AM · Restricted Project

Mar 24 2020

gilr added a comment to D76373: [LV] Replace stored value with a VPValue (NFCI).

LGTM, thanks! Please wait a day or so with committing, in case there are other comments.

Mar 24 2020, 10:44 AM · Restricted Project
gilr updated the diff for D76373: [LV] Replace stored value with a VPValue (NFCI).

Addressed comments.

Mar 24 2020, 9:39 AM · Restricted Project
gilr added inline comments to D76373: [LV] Replace stored value with a VPValue (NFCI).
Mar 24 2020, 9:39 AM · Restricted Project
gilr added a comment to D76373: [LV] Replace stored value with a VPValue (NFCI).

Ping :)

Mar 24 2020, 2:07 AM · Restricted Project

Mar 18 2020

gilr updated the diff for D76373: [LV] Replace stored value with a VPValue (NFCI).

Clang format.

Mar 18 2020, 1:35 PM · Restricted Project
gilr created D76373: [LV] Replace stored value with a VPValue (NFCI).
Mar 18 2020, 10:52 AM · Restricted Project

Mar 17 2020

gilr added a comment to D74695: [VPlan] Replace VPWidenRecipe with VPInstruction (WIP)..

I think doing so for VPWidenRecipe might be more tricky than other recipes, as VPWidenRecipe currently contains a list of instructions.
[snip]
I thought a little bit about how to migrate the def-use dependencies for VPWidenRecipe without breaking it up, but couldn't come up with a more straight-forward approach.

Mar 17 2020, 8:31 AM · Restricted Project

Mar 5 2020

gilr accepted D73078: [VPlan] Use consecutive numbers to print VPValues instead of addresses..

LGTM!

Mar 5 2020, 6:35 AM · Restricted Project

Mar 4 2020

gilr added a comment to D73078: [VPlan] Use consecutive numbers to print VPValues instead of addresses..

[snip]
I think we also introduce some VPInstructions not connected to any underlying IR during predication and will add more in the future. I think we should do (and need) both, using the IR name when available and the slot tracker otherwise. I think it would be good to have using the underlying IR names as a follow up to this patch. What do you think?

After D74445 all VPInstructions can indeed print themselves by either using their IR name or defaulting to SlotTracker/badref. So this patch can be simplified by not propagating the SlotTracker through the print() methods, since non-VPInstruction VPValues can rely on their underlying IR values for printing. Note that for this to work addVPValue must plant the underlying IR value into the generated VPValue as you do in D74695.
BackedgeTakenCount would then remain the only user of the current pointer-based naming and consequently of the "where:" clause.

Ah I think I got what you are proposing now: just remove the ::print(raw_ostream &O, const Twine &Indent, VPSlotTracker &SlotTracker) variants taking a SlotTracker, because we can just instantiate it on demand, by just getting the parent plan for the containing VPBB. This means we might have to re-number the plan multiple times when printing the whole plan through VPlanPrinter, but as this is just for debugging (and the scope of a plan should be relatively small) we can adjust that as follow-up, if required.

So the recursive print of any VP entity should use a single, up-to-date SlotTracker. This SlotTracker may be generated/assigned when entering the recursion (e.g. on operator<< or print()) and destroyed/invalidated when leaving it. One could optimize later to invalidate only when needed, i.e. on VPlan changes.

I think I am missing something.

I think this is exactly what the patch does: when calling print without SlotTracker, it will be created on demand and VPlanPrinter re-uses the same slot tracker for printing all VP entities by passing it to print(). I'm not sure what I should change, besides a follow-up to use the underlying values, if available/

Mar 4 2020, 9:00 AM · Restricted Project

Mar 3 2020

gilr added a comment to D73078: [VPlan] Use consecutive numbers to print VPValues instead of addresses..

[snip]
I think we also introduce some VPInstructions not connected to any underlying IR during predication and will add more in the future. I think we should do (and need) both, using the IR name when available and the slot tracker otherwise. I think it would be good to have using the underlying IR names as a follow up to this patch. What do you think?

After D74445 all VPInstructions can indeed print themselves by either using their IR name or defaulting to SlotTracker/badref. So this patch can be simplified by not propagating the SlotTracker through the print() methods, since non-VPInstruction VPValues can rely on their underlying IR values for printing. Note that for this to work addVPValue must plant the underlying IR value into the generated VPValue as you do in D74695.
BackedgeTakenCount would then remain the only user of the current pointer-based naming and consequently of the "where:" clause.

Ah I think I got what you are proposing now: just remove the ::print(raw_ostream &O, const Twine &Indent, VPSlotTracker &SlotTracker) variants taking a SlotTracker, because we can just instantiate it on demand, by just getting the parent plan for the containing VPBB. This means we might have to re-number the plan multiple times when printing the whole plan through VPlanPrinter, but as this is just for debugging (and the scope of a plan should be relatively small) we can adjust that as follow-up, if required.

Mar 3 2020, 8:34 AM · Restricted Project
gilr added a comment to D73078: [VPlan] Use consecutive numbers to print VPValues instead of addresses..

Updated patch to use getPlan(), add unit tests.

[snip]
I've put up a patch to add a pointer to VPlan: D74445. I;ve also added implementations of print() with and without SlotTracker (so we can re-use the existing tracker, e.g. from VPlanPrinter. I still need to update the slot tracker to actually use it. VPInstructions without a block (or a VPBasicBlock without parentPlan) should probably be handled similar to IR instructions without BB, by using something like 'badref'.

What do you think?

This added pointer to VPlan can indeed take care of enumerating VPInstructions, defaulting to 'badref'.
Essentially all other VPValues except BackedgeTakenCount are wrappers of underlying IR values (right?), so they can print that value e.g. with the proposed %ir. w/o needing SlotTracker's services, thereby simplifying the patch. This would leave the somewhat special BackedgeTakenCount as the only user of the "where:" clause and current pointer-based naming.

I think we also introduce some VPInstructions not connected to any underlying IR during predication and will add more in the future. I think we should do (and need) both, using the IR name when available and the slot tracker otherwise. I think it would be good to have using the underlying IR names as a follow up to this patch. What do you think?

Mar 3 2020, 3:04 AM · Restricted Project
gilr accepted D74445: [VPlan] Add ParentPlan pointer to VPBlockBase..

LGTM, with minor fix.

Mar 3 2020, 2:12 AM · Restricted Project

Mar 1 2020

gilr added a comment to D73078: [VPlan] Use consecutive numbers to print VPValues instead of addresses..

[snip]
I've put up a patch to add a pointer to VPlan: D74445. I;ve also added implementations of print() with and without SlotTracker (so we can re-use the existing tracker, e.g. from VPlanPrinter. I still need to update the slot tracker to actually use it. VPInstructions without a block (or a VPBasicBlock without parentPlan) should probably be handled similar to IR instructions without BB, by using something like 'badref'.

What do you think?

Mar 1 2020, 8:59 AM · Restricted Project
gilr added a comment to D74445: [VPlan] Add ParentPlan pointer to VPBlockBase..

An alternative to adding a VPlan* to every VP block might be to reuse their existing Parent property by having (only) the topmost block's parent point to VPlan, similar to the IR hierarchy where ancestors are reached indirectly through transitivity. This would require VPlan to inherit from VPRegion, which may deserve further discussion.
For now let's go ahead with the suggested VPlan pointer in VPBlockBase, but better just call it get/Plan instead of get/ParentPlan, saving parenthood's existing semantics.
Since the only current use case for this is debugging, we can simplify the patch and maintain a future trivial switch to the above by setting only the entry block's VPlan e.g. at VPlan::setEntry() and have getPlan() traverse upwards until reaching a topmost block and backwards until reaching the entry. This also better supports potential moving blocks in and out of VPlans.
Makes sense?

Mar 1 2020, 7:02 AM · Restricted Project

Feb 5 2020

gilr added a comment to D73078: [VPlan] Use consecutive numbers to print VPValues instead of addresses..

It would indeed be good to improve VPValue printing. Initially, there were only a handful of VPValues so those pointer-based IDs seemed sufficient.
Since VPValues are now both more common and optionally have an underlying IR value, retaining names from the underlying IR where available could go a long way w.r.t both readability and relating to the loop being vectorized; This would hopefully cover most VPValues.

Sounds good, printing the name of the underlying value should be quite trivial.

BTW, VP basic blocks could also retain the name of the corresponding IR basic block.

Sounds good!

It would also be good to distinguish between "pure" VPValues and VPValues wrapping unnamed IR values (can we somehow retain the latter's enumeration?)

+1. I think we would still need a mechanism like this patch to provide a better numbering for 'pure' VPValues.

Feb 5 2020, 6:48 AM · Restricted Project

Feb 3 2020

gilr added a comment to D73078: [VPlan] Use consecutive numbers to print VPValues instead of addresses..

It would indeed be good to improve VPValue printing. Initially, there were only a handful of VPValues so those pointer-based IDs seemed sufficient.
Since VPValues are now both more common and optionally have an underlying IR value, retaining names from the underlying IR where available could go a long way w.r.t both readability and relating to the loop being vectorized; This would hopefully cover most VPValues.
BTW, VP basic blocks could also retain the name of the corresponding IR basic block.
It would also be good to distinguish between "pure" VPValues and VPValues wrapping unnamed IR values (can we somehow retain the latter's enumeration?)

Feb 3 2020, 1:41 AM · Restricted Project

Jan 27 2020

gilr accepted D73423: [LV] Do not try to sink dead instructions..

LGTM!

Jan 27 2020, 10:25 PM · Restricted Project
gilr added inline comments to D73423: [LV] Do not try to sink dead instructions..
Jan 27 2020, 5:08 AM · Restricted Project

Jan 26 2020

gilr added inline comments to D73423: [LV] Do not try to sink dead instructions..
Jan 26 2020, 4:11 AM · Restricted Project

Jan 9 2020

gilr committed rG8647a72c4a52: [LV] VPValues for memory operation pointers (NFCI) (authored by gilr).
[LV] VPValues for memory operation pointers (NFCI)
Jan 9 2020, 11:37 PM
gilr closed D70865: [LV] VPValues for memory operation pointers (NFCI).
Jan 9 2020, 11:37 PM · Restricted Project

Jan 8 2020

gilr added a comment to D70865: [LV] VPValues for memory operation pointers (NFCI).

Adding minor comments; may be good to have consistent naming of VPValue variables and their corresponding code-gen'd Values(?).

Jan 8 2020, 4:44 AM · Restricted Project
gilr updated the diff for D70865: [LV] VPValues for memory operation pointers (NFCI).

Addressed comments.

Jan 8 2020, 4:44 AM · Restricted Project

Jan 6 2020

gilr added inline comments to D68814: [LV] Allow assume calls in predicated blocks..
Jan 6 2020, 5:10 AM · Restricted Project

Dec 29 2019

gilr updated the diff for D70865: [LV] VPValues for memory operation pointers (NFCI).

Addressed comments.

Dec 29 2019, 1:09 AM · Restricted Project

Dec 28 2019

gilr committed rGd62bf16131e4: [LV] Use getMask() when printing recipe [NFCI] (authored by gilr).
[LV] Use getMask() when printing recipe [NFCI]
Dec 28 2019, 11:11 PM
gilr closed D71964: [LV] Use getMask() when printing recipe [NFCI].
Dec 28 2019, 11:11 PM · Restricted Project
gilr added a comment to D71964: [LV] Use getMask() when printing recipe [NFCI].

LGTM

Dec 28 2019, 11:11 PM · Restricted Project
gilr added inline comments to D70865: [LV] VPValues for memory operation pointers (NFCI).
Dec 28 2019, 9:58 AM · Restricted Project
gilr retitled D71964: [LV] Use getMask() when printing recipe [NFCI] from [LV] Use getMask() when printing recipe to [LV] Use getMask() when printing recipe [NFCI].
Dec 28 2019, 9:58 AM · Restricted Project
gilr created D71964: [LV] Use getMask() when printing recipe [NFCI].
Dec 28 2019, 9:39 AM · Restricted Project

Dec 9 2019

gilr updated the diff for D70865: [LV] VPValues for memory operation pointers (NFCI).

Addressed comments.

Dec 9 2019, 12:34 PM · Restricted Project
gilr added inline comments to D70865: [LV] VPValues for memory operation pointers (NFCI).
Dec 9 2019, 12:25 PM · Restricted Project

Dec 7 2019

gilr added a comment to D70734: [VPlan] Add basicblocks() and loop_basicblocks iterators..

Traversing VPRegions is not supported at the moment but we do not create such plans at the moment as far as I know

I assume you're referring to the native path? (non-native generates regions for scalarized & predicated instructions)

Ah right, I missed that code path! For my initial use-case (dropping assumes), the iterator needs to traverse the regions as well then. Let's see if I can get the iterators to co-operate. Do you think it's worth to get the existing iterators in as is? There are a few places that could use them, I think.

Dec 7 2019, 1:43 AM · Restricted Project

Dec 6 2019

gilr accepted D70732: [VPlan] Rename VPlanHCFGTransforms to VPlanTransforms (NFC)..

LGTM!

Dec 6 2019, 10:43 PM · Restricted Project
gilr added inline comments to D70732: [VPlan] Rename VPlanHCFGTransforms to VPlanTransforms (NFC)..
Dec 6 2019, 11:28 AM · Restricted Project
gilr committed rG39ccc099c901: [LV] Record GEP widening decisions in recipe (NFCI) (authored by gilr).
[LV] Record GEP widening decisions in recipe (NFCI)
Dec 6 2019, 3:53 AM
gilr closed D69067: [LV] Record GEP widening decisions in recipe (NFCI).
Dec 6 2019, 3:52 AM · Restricted Project
gilr updated the diff for D69067: [LV] Record GEP widening decisions in recipe (NFCI).

Addressed final comment (thanks Florian!)

Dec 6 2019, 2:29 AM · Restricted Project
gilr added inline comments to D68814: [LV] Allow assume calls in predicated blocks..
Dec 6 2019, 1:45 AM · Restricted Project

Dec 1 2019

gilr updated the diff for D69067: [LV] Record GEP widening decisions in recipe (NFCI).

Addressed comments.

Dec 1 2019, 1:36 AM · Restricted Project

Nov 29 2019

gilr abandoned D70054: [LV] Move pointer inspection from ILV to recipe (NFCI).

A more comprehensive solution for breaking this ingredient def-use dependence is implemented in D70865.

Nov 29 2019, 11:19 PM · Restricted Project
gilr created D70865: [LV] VPValues for memory operation pointers (NFCI).
Nov 29 2019, 11:51 AM · Restricted Project
gilr accepted D70733: [VPlan] Move graph traits (NFC)..
Nov 29 2019, 10:49 AM · Restricted Project
gilr added a comment to D70734: [VPlan] Add basicblocks() and loop_basicblocks iterators..

Traversing VPRegions is not supported at the moment but we do not create such plans at the moment as far as I know

Nov 29 2019, 10:38 AM · Restricted Project

Nov 25 2019

gilr updated the diff for D69067: [LV] Record GEP widening decisions in recipe (NFCI).
  • Limit this commit to handling GEP widening only, per Ayal's comment.
  • Bug fix: The all-operands-are-invariant check was not checking the pointer's invariance.
Nov 25 2019, 5:35 AM · Restricted Project

Nov 10 2019

gilr added a comment to D70054: [LV] Move pointer inspection from ILV to recipe (NFCI).

Originally part of D69067, to be reviewed separately per Ayal's comment.

Nov 10 2019, 9:47 AM · Restricted Project
gilr created D70054: [LV] Move pointer inspection from ILV to recipe (NFCI).
Nov 10 2019, 9:38 AM · Restricted Project

Nov 9 2019

gilr added a comment to D68577: [LV] Apply sink-after & interleave-groups as VPlan transformations (NFC).

Testcase follows; reproduce with opt -loop-vectorize:

Nov 9 2019, 11:02 PM · Restricted Project
gilr committed rG7f152543e4ff: [LV] Apply sink-after & interleave-groups as VPlan transformations (NFCI) (authored by gilr).
[LV] Apply sink-after & interleave-groups as VPlan transformations (NFCI)
Nov 9 2019, 10:59 AM

Nov 8 2019

gilr committed rG9f08ce0d2197: Revert "[LV] Apply sink-after & interleave-groups as VPlan transformations… (authored by gilr).
Revert "[LV] Apply sink-after & interleave-groups as VPlan transformations…
Nov 8 2019, 12:25 PM
gilr added a reverting change for rG11ed1c0239fd: [LV] Apply sink-after & interleave-groups as VPlan transformations (NFCI): rG9f08ce0d2197: Revert "[LV] Apply sink-after & interleave-groups as VPlan transformations….
Nov 8 2019, 12:25 PM
gilr added a comment to D68577: [LV] Apply sink-after & interleave-groups as VPlan transformations (NFC).

Please let me know if you need me to come up with a testcase.

Nov 8 2019, 12:06 PM · Restricted Project
gilr updated subscribers of D68577: [LV] Apply sink-after & interleave-groups as VPlan transformations (NFC).

Gil, I can put a patch up for not sinking past terminators in OVDescriptor, as I am already working on patches in that area.

I’d also suggest to land the removeFromParent & co changes separately from the other changes in the patch.

Nov 8 2019, 5:47 AM · Restricted Project
gilr committed rG11ed1c0239fd: [LV] Apply sink-after & interleave-groups as VPlan transformations (NFCI) (authored by gilr).
[LV] Apply sink-after & interleave-groups as VPlan transformations (NFCI)
Nov 8 2019, 5:32 AM

Nov 5 2019

gilr added a comment to D68577: [LV] Apply sink-after & interleave-groups as VPlan transformations (NFC).
Nov 5 2019, 11:28 PM · Restricted Project
gilr committed rG100e797adb43: [LV] Apply sink-after & interleave-groups as VPlan transformations (NFC) (authored by gilr).
[LV] Apply sink-after & interleave-groups as VPlan transformations (NFC)
Nov 5 2019, 7:33 AM

Nov 4 2019

gilr committed rG2be17087f8c3: [LV] Apply sink-after & interleave-groups as VPlan transformations (NFC) (authored by gilr).
[LV] Apply sink-after & interleave-groups as VPlan transformations (NFC)
Nov 4 2019, 1:09 AM
gilr closed D68577: [LV] Apply sink-after & interleave-groups as VPlan transformations (NFC).
Nov 4 2019, 1:09 AM · Restricted Project

Nov 3 2019

gilr updated the diff for D68577: [LV] Apply sink-after & interleave-groups as VPlan transformations (NFC).

Addressed comments.

Nov 3 2019, 8:58 AM · Restricted Project
gilr added a comment to D68577: [LV] Apply sink-after & interleave-groups as VPlan transformations (NFC).

Thanks everyone!

Nov 3 2019, 8:55 AM · Restricted Project
gilr updated the diff for D69067: [LV] Record GEP widening decisions in recipe (NFCI).

Address comments.

Nov 3 2019, 8:19 AM · Restricted Project
gilr added inline comments to D69067: [LV] Record GEP widening decisions in recipe (NFCI).
Nov 3 2019, 7:55 AM · Restricted Project