Page MenuHomePhabricator

gilr (Gil Rapaport)
User

Projects

User does not belong to any projects.

User Details

User Since
Nov 12 2014, 11:00 PM (323 w, 3 d)

Recent Activity

Yesterday

gilr added inline comments to D92282: [VPlan] Handle scalarized values in VPTransformState..
Sat, Jan 23, 11:59 PM · Restricted Project

Tue, Jan 19

gilr added a comment to D92284: [VPlan] Manage induction value creation using VPValues..

Should the (final) goal be to move the whole phi-trunc-cast logic from code-gen to vplanning phase?

Tue, Jan 19, 2:39 PM · Restricted Project
gilr added inline comments to D92282: [VPlan] Handle scalarized values in VPTransformState..
Tue, Jan 19, 7:37 AM · Restricted Project

Wed, Jan 13

gilr added a comment to D93974: [ValueTracking] Safe assumption context for args.

Oh.. this is bad. That happens if you mix two logically differnet things into a single instruction pointer.
I put it on the list of things that need to fixed wrt. assumes ... :(

Wed, Jan 13, 2:30 PM · Restricted Project

Tue, Jan 12

gilr added a comment to D93974: [ValueTracking] Safe assumption context for args.

Yes, if isaAssumeIntrinsic stands for "is an assume or an ephemeral of an assume".

Why is anything but an llvm.assume a problem? (Sorry I have so many questions)

Tue, Jan 12, 1:41 PM · Restricted Project
gilr added a comment to D93974: [ValueTracking] Safe assumption context for args.

The idea is that you can always do what you do here in isValidAssumeForContext (and friends). I just checked and we seem to do so already. Could you explain to me why we need to go for the Last instruction in this patch at all? What would happen if you simply pick the first in the entry block, which is trivially correct. (Note: You can skip llvm.assume to make some weird problems go away).

The patch indeed defaults to the first instruction in the entry. Scanning to the end at safeCxtI() was an optimization for cases where the first instruction is an ephemeral value of an assume (which seems quite likely for assumes about arguments) that would get the assume discarded by the isEphemeralValueOf(Inv, CxtI) check. At isValidAssumeForContext() we can't distinguish between a context given only as a control-flow marker and a context that also guards against simplifying an ephemeral so we can't try to improve it there, but since any context safeCxtI() provides for a null CxtI is just a control-flow marker anyway we might as well choose one that's not an ephemeral of any assume in the entry block. Does that make sense?

Yes. But your code does "more" than that. All you want is this pseudo-code, right?

auto &It = EntryBlock.begin();
while (isaAssumeIntrinsic(*It)) ++It;
return *It;
Tue, Jan 12, 10:24 AM · Restricted Project
gilr added a comment to D93974: [ValueTracking] Safe assumption context for args.
Tue, Jan 12, 9:33 AM · Restricted Project
gilr added a comment to D94088: [SCEV] Assumption context for GetMinTrailingZeros.

Ping :)

Tue, Jan 12, 4:46 AM · Restricted Project
gilr added a comment to D93974: [ValueTracking] Safe assumption context for args.

FWIW, I agree with @nikic, we should not put this logic here. There are two problems:

  1. We compute something we might not need.
  2. We do it only in value tracking.
Tue, Jan 12, 3:57 AM · Restricted Project

Fri, Jan 8

gilr accepted D93975: [VPlan] Keep start value of VPWidenPHIRecipe as VPValue..

LGTM!

Fri, Jan 8, 11:24 PM · Restricted Project
gilr accepted D94175: [VPlan] Move reduction start value creation to widenPHIRecipe..

LGTM, with a nit.
(Seems reduction might be worth splitting widenPhiInstruction() and its own Recipe, but that's beyond the scope of this patch)
Thanks!

Fri, Jan 8, 8:40 AM · Restricted Project

Thu, Jan 7

gilr updated the diff for D94088: [SCEV] Assumption context for GetMinTrailingZeros.

Rebased on top of 7ddbe0cb905ec62d37b284a2e8daf54887a35f94 (merge ..-assume-divisible-TC.ll into ..-divisible-TC.ll)

Thu, Jan 7, 12:36 AM · Restricted Project

Wed, Jan 6

gilr committed rG7ddbe0cb905e: [LV] Merge tests into a single file (NFC) (authored by gilr).
[LV] Merge tests into a single file (NFC)
Wed, Jan 6, 11:12 PM
gilr updated the diff for D94088: [SCEV] Assumption context for GetMinTrailingZeros.

Addressed comments.

Wed, Jan 6, 1:01 AM · Restricted Project
gilr added inline comments to D94088: [SCEV] Assumption context for GetMinTrailingZeros.
Wed, Jan 6, 12:56 AM · Restricted Project

Tue, Jan 5

gilr added a comment to D93974: [ValueTracking] Safe assumption context for args.

Sorry for the delay @nikic.

Am I understanding correctly that this tries to use the last instruction in the entry block rather than the first one to avoid triggering the ephemeral value check, in case the first instruction is part of an assumption?

Yes, the first instruction is fine except for an assume which appears (along with its ephemeral values) as the first thing in the function, which in case of an argument seems quite likely.

In any case, I don't think it's appropriate to perform a full block scan to determine the context instruction. safeCxtI() should be cheap (as in O(1)).

An unbounded scan of the entry block might indeed be too much even if applied only to arguments. The scan can perhaps be limited to some small number of instructions (5 seems like the minimum to cover most patterns in computeKnownBits()) which gets reset if an assume is encountered.

Another possibility would be to leave the context instruction at nullptr, and instead adjust isValidAssumeForContext to accept a nullptr CxtI in which case only instructions that are must-exec from the function entry are considered. Advantage is that it only incurs a cost if there is a potentially relevant assume.

Tue, Jan 5, 1:43 PM · Restricted Project
gilr added a comment to D93975: [VPlan] Keep start value of VPWidenPHIRecipe as VPValue..

I wonder if the code from fixReductions() could be moved (almost as-is) to widenPHIInstruction() as a first step?

Tue, Jan 5, 11:28 AM · Restricted Project
gilr updated subscribers of D94088: [SCEV] Assumption context for GetMinTrailingZeros.
Tue, Jan 5, 8:20 AM · Restricted Project
gilr requested review of D94088: [SCEV] Assumption context for GetMinTrailingZeros.
Tue, Jan 5, 7:34 AM · Restricted Project
gilr added a comment to D93974: [ValueTracking] Safe assumption context for args.

Sorry for the delay @nikic.

Tue, Jan 5, 7:01 AM · Restricted Project

Sun, Jan 3

gilr committed rGd9c0b128e354: [SCEV] Simplify trunc to zero based on known bits (authored by gilr).
[SCEV] Simplify trunc to zero based on known bits
Sun, Jan 3, 4:08 AM
gilr closed D93973: [SCEV] Simplify trunc to zero based on known bits.
Sun, Jan 3, 4:08 AM · Restricted Project
gilr added inline comments to D93973: [SCEV] Simplify trunc to zero based on known bits.
Sun, Jan 3, 3:54 AM · Restricted Project

Sat, Jan 2

gilr updated the diff for D93973: [SCEV] Simplify trunc to zero based on known bits.

Limit trailing-zeros check to SCEVUnknowns and only while depth limit is not reached.

Sat, Jan 2, 11:31 PM · Restricted Project
gilr added inline comments to D93973: [SCEV] Simplify trunc to zero based on known bits.
Sat, Jan 2, 11:27 PM · Restricted Project
gilr updated the diff for D93973: [SCEV] Simplify trunc to zero based on known bits.

Addressed comments.

Sat, Jan 2, 7:45 AM · Restricted Project
gilr committed rGd8af31006351: [LV] Add missed optimization fold-tail test (authored by gilr).
[LV] Add missed optimization fold-tail test
Sat, Jan 2, 4:02 AM
gilr requested review of D93974: [ValueTracking] Safe assumption context for args.
Sat, Jan 2, 12:05 AM · Restricted Project

Fri, Jan 1

gilr requested review of D93973: [SCEV] Simplify trunc to zero based on known bits.
Fri, Jan 1, 11:59 PM · Restricted Project

Dec 22 2020

gilr accepted D93677: [LV] Use ScalarEvolution::getURemExpr to reduce duplication..

LGTM, thanks!

Dec 22 2020, 5:49 AM · Restricted Project
gilr committed rGa56280094e08: [LV] Avoid needless fold tail (authored by gilr).
[LV] Avoid needless fold tail
Dec 22 2020, 12:26 AM
gilr closed D93615: [LV] Avoid needless fold tail.
Dec 22 2020, 12:26 AM · Restricted Project
gilr added inline comments to D93615: [LV] Avoid needless fold tail.
Dec 22 2020, 12:02 AM · Restricted Project

Dec 21 2020

gilr updated the diff for D93615: [LV] Avoid needless fold tail.

Add a test for a constant TC with IC=3.

Dec 21 2020, 5:42 AM · Restricted Project
gilr added inline comments to D93615: [LV] Avoid needless fold tail.
Dec 21 2020, 5:33 AM · Restricted Project
gilr added a reviewer for D93615: [LV] Avoid needless fold tail: SjoerdMeijer.
Dec 21 2020, 12:18 AM · Restricted Project

Dec 20 2020

gilr requested review of D93615: [LV] Avoid needless fold tail.
Dec 20 2020, 11:29 PM · Restricted Project
gilr accepted D90562: [VPlan] Use VPDef for VPInterleaveRecipe..

LGTM!

Dec 20 2020, 10:38 PM · Restricted Project
gilr added inline comments to D90562: [VPlan] Use VPDef for VPInterleaveRecipe..
Dec 20 2020, 1:57 AM · Restricted Project

Dec 16 2020

gilr added inline comments to D90562: [VPlan] Use VPDef for VPInterleaveRecipe..
Dec 16 2020, 5:23 AM · Restricted Project
gilr added inline comments to D90562: [VPlan] Use VPDef for VPInterleaveRecipe..
Dec 16 2020, 12:49 AM · Restricted Project

Dec 15 2020

gilr accepted D90560: [VPlan] Use VPDef for VPWidenSelectRecipe..

LGTM, tx!

Dec 15 2020, 5:42 AM · Restricted Project

Dec 14 2020

gilr added a comment to D90560: [VPlan] Use VPDef for VPWidenSelectRecipe..

How is the new test related to this change?

Dec 14 2020, 11:16 PM · Restricted Project
gilr accepted D90559: [VPlan] Use VPdef for VPWidenCall..
Dec 14 2020, 11:12 PM · Restricted Project
gilr accepted D90561: [VPlan] Use VPDef for VPWidenGEPRecipe..
Dec 14 2020, 11:12 PM · Restricted Project
gilr accepted D90563: [VPlan] Make VPWidenMemoryInstructionRecipe a VPDef..

LGTM, tx!

Dec 14 2020, 5:25 AM · Restricted Project
gilr added inline comments to D90563: [VPlan] Make VPWidenMemoryInstructionRecipe a VPDef..
Dec 14 2020, 2:58 AM · Restricted Project

Nov 28 2020

gilr accepted D90565: [VPlan] Make VPInstruction a VPDef.

LGTM, tx!

Nov 28 2020, 9:47 AM · Restricted Project

Nov 24 2020

gilr accepted D90564: [VPlan] Make VPRecipeBase inherit from VPDef..

LGTM, tx!

Nov 24 2020, 9:08 AM · Restricted Project
gilr requested changes to D90564: [VPlan] Make VPRecipeBase inherit from VPDef..
Nov 24 2020, 6:09 AM · Restricted Project

Nov 22 2020

gilr added inline comments to D90564: [VPlan] Make VPRecipeBase inherit from VPDef..
Nov 22 2020, 5:33 AM · Restricted Project

Nov 15 2020

gilr added inline comments to D90565: [VPlan] Make VPInstruction a VPDef.
Nov 15 2020, 3:05 AM · Restricted Project

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