Page MenuHomePhabricator

guopeilin (guopeilin)
User

Projects

User does not belong to any projects.

User Details

User Since
Nov 11 2020, 3:34 AM (26 w, 2 d)

Recent Activity

Fri, May 7

guopeilin committed rG911a541620bc: [LazyValueInfo] Insert an Overdefined placeholder to prevent infinite recursion (authored by guopeilin).
[LazyValueInfo] Insert an Overdefined placeholder to prevent infinite recursion
Fri, May 7, 1:07 AM
guopeilin closed D101273: [LazyValueInfo] Insert an Overdefined placeholder to prevent infinite recursion.
Fri, May 7, 1:07 AM · Restricted Project

Wed, May 5

guopeilin updated the summary of D101273: [LazyValueInfo] Insert an Overdefined placeholder to prevent infinite recursion.
Wed, May 5, 11:44 PM · Restricted Project
guopeilin updated the diff for D101273: [LazyValueInfo] Insert an Overdefined placeholder to prevent infinite recursion.
Wed, May 5, 11:38 PM · Restricted Project

Wed, Apr 28

guopeilin added a comment to D101273: [LazyValueInfo] Insert an Overdefined placeholder to prevent infinite recursion.

@nikic Thanks a lot so your suggesstion. A new patch updated, please review.

Wed, Apr 28, 7:28 PM · Restricted Project
guopeilin updated the diff for D101273: [LazyValueInfo] Insert an Overdefined placeholder to prevent infinite recursion.
Wed, Apr 28, 7:25 PM · Restricted Project
guopeilin added a reviewer for D101273: [LazyValueInfo] Insert an Overdefined placeholder to prevent infinite recursion: fhahn.
Wed, Apr 28, 12:33 AM · Restricted Project
guopeilin added a reviewer for D101273: [LazyValueInfo] Insert an Overdefined placeholder to prevent infinite recursion: apilipenko.
Wed, Apr 28, 12:30 AM · Restricted Project

Tue, Apr 27

guopeilin added a comment to D101273: [LazyValueInfo] Insert an Overdefined placeholder to prevent infinite recursion.

@guopeilin getValueFromCondition() uses a Visited set that should be used to prevent this. You need to insert an Overdefined placeholder into the set before computing the actual value.

Tue, Apr 27, 6:57 PM · Restricted Project
guopeilin updated the diff for D101273: [LazyValueInfo] Insert an Overdefined placeholder to prevent infinite recursion.

Fix bugs in Lazy Value Info analysis rather in Jump Threading pass

Tue, Apr 27, 6:56 PM · Restricted Project

Mon, Apr 26

guopeilin added a comment to D101273: [LazyValueInfo] Insert an Overdefined placeholder to prevent infinite recursion.

https://bugs.llvm.org/show_bug.cgi?id=50119
The bug is that we will be trapped into an infinite loop when we doing jump threading pass, and finally exhaust the stack.
The Jump Threading call function getValueFromCondition() of LazyValueInfo, and this function will recursively call itself in a way shown in the fowllowing:

BinaryOperator *BO = dyn_cast<BinaryOperator>(Cond);
Value *BL = BO->getOperand(0);
Value *BR = BO->getOperand(1);
Mon, Apr 26, 1:50 AM · Restricted Project
guopeilin added a reviewer for D101273: [LazyValueInfo] Insert an Overdefined placeholder to prevent infinite recursion: mdchen.
Mon, Apr 26, 1:35 AM · Restricted Project

Sun, Apr 25

guopeilin added reviewers for D101273: [LazyValueInfo] Insert an Overdefined placeholder to prevent infinite recursion: lattner, Nicola, brzycki.
Sun, Apr 25, 7:59 PM · Restricted Project
guopeilin added a comment to D101273: [LazyValueInfo] Insert an Overdefined placeholder to prevent infinite recursion.

Right now this patch set the argument KeepOneInputPHIs of function DeleteDeadBlocks to be true, that is we only allow replacing the phi node with its incoming value if this incoming value is a constant

Sun, Apr 25, 7:55 PM · Restricted Project
guopeilin added a comment to D101273: [LazyValueInfo] Insert an Overdefined placeholder to prevent infinite recursion.

Sun, Apr 25, 7:31 PM · Restricted Project
guopeilin added a comment to D101273: [LazyValueInfo] Insert an Overdefined placeholder to prevent infinite recursion.
Sun, Apr 25, 7:29 PM · Restricted Project
guopeilin requested review of D101273: [LazyValueInfo] Insert an Overdefined placeholder to prevent infinite recursion.
Sun, Apr 25, 7:27 PM · Restricted Project

Jan 19 2021

guopeilin added a comment to D93617: [LoopVectorize] Take non-instruction's size into consideration when computing leader's demanded bits.

A new patch has been updated, could you please review it. Thanks a lot.

Jan 19 2021, 7:21 PM · Restricted Project

Jan 7 2021

guopeilin added inline comments to D93617: [LoopVectorize] Take non-instruction's size into consideration when computing leader's demanded bits.
Jan 7 2021, 10:32 PM · Restricted Project
guopeilin updated the diff for D93617: [LoopVectorize] Take non-instruction's size into consideration when computing leader's demanded bits.
Jan 7 2021, 10:18 PM · Restricted Project

Jan 6 2021

guopeilin added inline comments to D93617: [LoopVectorize] Take non-instruction's size into consideration when computing leader's demanded bits.
Jan 6 2021, 6:24 PM · Restricted Project
guopeilin added inline comments to D93617: [LoopVectorize] Take non-instruction's size into consideration when computing leader's demanded bits.
Jan 6 2021, 6:08 PM · Restricted Project

Jan 4 2021

guopeilin added inline comments to D91512: [AArch64][Isel] Avoid implicit zext for SIGN_EXTEND_INREG ( TRUNCATE ).
Jan 4 2021, 1:34 AM · Restricted Project
guopeilin added inline comments to D93617: [LoopVectorize] Take non-instruction's size into consideration when computing leader's demanded bits.
Jan 4 2021, 1:32 AM · Restricted Project
guopeilin added inline comments to D93617: [LoopVectorize] Take non-instruction's size into consideration when computing leader's demanded bits.
Jan 4 2021, 1:31 AM · Restricted Project
guopeilin updated the diff for D93617: [LoopVectorize] Take non-instruction's size into consideration when computing leader's demanded bits.
Jan 4 2021, 1:18 AM · Restricted Project

Dec 29 2020

guopeilin added a comment to D93617: [LoopVectorize] Take non-instruction's size into consideration when computing leader's demanded bits.

Okay, based on your description this *is* a correctness fix, but it's not applied to the right place. The result of the DemandedBits analysis is correct -- demanded bits of the trunc operand are the same as for the trunc result.

As far as I can tell, the actual bug is in computeMinimumValueSizes(). It "successfully" terminates walks at non-Instructions, but that's not right, as the demanded bits for the non-Instruction can be wider. In your avoid-truncate-shift-operands.ll example, note that in lshr i32 %f, 18, %f has demanded bits outside the low 16 bits, but this fact is lost, because %f is an Argument. I imagine the same thing happens with constants as well. The fact that Arguments are incorrectly truncated seems to be the commonality between all your tests.

As such, I believe a fix here needs to be in computeMinimumValueSizes() -- though possibly DemandedBits also needs to be extended to provide additional information.

A possible way to go about this is to extended the existing DemandedBits code for DeadUses, which currently stores whether certain Uses are completely dead. This could be changed to actually store the demanded bits per-use, not just per-instruction. This would allow you to inspect the demanded bits of arguments and constants as used in a specific instruction. We would have to evaluate the additional cost this would have though.

Dec 29 2020, 2:55 AM · Restricted Project
guopeilin added a comment to D93617: [LoopVectorize] Take non-instruction's size into consideration when computing leader's demanded bits.

This causes a number of test failures:

Failed Tests (4):
  LLVM :: Transforms/LoopVectorize/AArch64/deterministic-type-shrinkage.ll
  LLVM :: Transforms/LoopVectorize/AArch64/loop-vectorization-factors.ll
  LLVM :: Transforms/LoopVectorize/ARM/tail-folding-reduces-vf.ll
  LLVM :: Transforms/LoopVectorize/demanded-bits-of-pointer-instruction.ll

Last one is an assertion failure because you assume non-pointer types, the others are presumably optimization regressions. What you are effectively doing here is to disable the truncation optimization completely for any case where the instruction chain contains an argument or a constant somewhere. Especially the latter case is probably very common. So while this change does fix the miscompile, it effectively disables the optimization entirely, which is probably not desired.

Dec 29 2020, 2:53 AM · Restricted Project
guopeilin updated the diff for D93617: [LoopVectorize] Take non-instruction's size into consideration when computing leader's demanded bits.
Dec 29 2020, 2:48 AM · Restricted Project

Dec 25 2020

guopeilin added a comment to D93617: [LoopVectorize] Take non-instruction's size into consideration when computing leader's demanded bits.

Please upload patches with full context (-U9999)

Dec 25 2020, 1:49 AM · Restricted Project
guopeilin updated the diff for D93617: [LoopVectorize] Take non-instruction's size into consideration when computing leader's demanded bits.
Dec 25 2020, 1:45 AM · Restricted Project

Dec 24 2020

guopeilin added a comment to D93617: [LoopVectorize] Take non-instruction's size into consideration when computing leader's demanded bits.

Okay, based on your description this *is* a correctness fix, but it's not applied to the right place. The result of the DemandedBits analysis is correct -- demanded bits of the trunc operand are the same as for the trunc result.

As far as I can tell, the actual bug is in computeMinimumValueSizes(). It "successfully" terminates walks at non-Instructions, but that's not right, as the demanded bits for the non-Instruction can be wider. In your avoid-truncate-shift-operands.ll example, note that in lshr i32 %f, 18, %f has demanded bits outside the low 16 bits, but this fact is lost, because %f is an Argument. I imagine the same thing happens with constants as well. The fact that Arguments are incorrectly truncated seems to be the commonality between all your tests.

As such, I believe a fix here needs to be in computeMinimumValueSizes() -- though possibly DemandedBits also needs to be extended to provide additional information.

A possible way to go about this is to extended the existing DemandedBits code for DeadUses, which currently stores whether certain Uses are completely dead. This could be changed to actually store the demanded bits per-use, not just per-instruction. This would allow you to inspect the demanded bits of arguments and constants as used in a specific instruction. We would have to evaluate the additional cost this would have though.

Dec 24 2020, 10:45 PM · Restricted Project
guopeilin updated the diff for D93617: [LoopVectorize] Take non-instruction's size into consideration when computing leader's demanded bits.
Dec 24 2020, 10:39 PM · Restricted Project

Dec 23 2020

guopeilin added a comment to D93617: [LoopVectorize] Take non-instruction's size into consideration when computing leader's demanded bits.

Can you please start with filing a bugreport, explaining the miscompile(?), with tests?

Dec 23 2020, 5:19 AM · Restricted Project
guopeilin added a comment to D93617: [LoopVectorize] Take non-instruction's size into consideration when computing leader's demanded bits.

bugzilla : https://bugs.llvm.org/show_bug.cgi?id=48583

Dec 23 2020, 5:13 AM · Restricted Project
guopeilin added a comment to D93617: [LoopVectorize] Take non-instruction's size into consideration when computing leader's demanded bits.

Okay, based on your description this *is* a correctness fix, but it's not applied to the right place. The result of the DemandedBits analysis is correct -- demanded bits of the trunc operand are the same as for the trunc result.

As far as I can tell, the actual bug is in computeMinimumValueSizes(). It "successfully" terminates walks at non-Instructions, but that's not right, as the demanded bits for the non-Instruction can be wider. In your avoid-truncate-shift-operands.ll example, note that in lshr i32 %f, 18, %f has demanded bits outside the low 16 bits, but this fact is lost, because %f is an Argument. I imagine the same thing happens with constants as well. The fact that Arguments are incorrectly truncated seems to be the commonality between all your tests.

As such, I believe a fix here needs to be in computeMinimumValueSizes() -- though possibly DemandedBits also needs to be extended to provide additional information.

A possible way to go about this is to extended the existing DemandedBits code for DeadUses, which currently stores whether certain Uses are completely dead. This could be changed to actually store the demanded bits per-use, not just per-instruction. This would allow you to inspect the demanded bits of arguments and constants as used in a specific instruction. We would have to evaluate the additional cost this would have though.

Thanks for reviewing.
And I still get confused in some places. One is that the DemandedBits.cpp seems compute the demandedbits per-instruction, that is it "successfully" terminates walks at non-Instructions, too.
I guess the way computing demanded-bits per-instruction is not compatible with the way truncateToMinimalBitwidths() truncating the operands for every instruction in MinBWs.
So if we still want keep truncateToMinimalBitwidths(), then we may need modify function computeMinimumValueSizes() to take Arguments into consideration, Or if we still want to compute demanded bits in per-instruction way, then is it a possible solution that we be more conservative in function truncateToMinimalBitwidths(), that is we add some patterns, if match then avoid truncating?

Dec 23 2020, 4:21 AM · Restricted Project

Dec 21 2020

guopeilin updated the diff for D93617: [LoopVectorize] Take non-instruction's size into consideration when computing leader's demanded bits.
Dec 21 2020, 2:11 AM · Restricted Project
guopeilin added a comment to D93617: [LoopVectorize] Take non-instruction's size into consideration when computing leader's demanded bits.

To avoid wrongly truncating operands, I add a whitelist for computing demanded bits of Instruction::Trunc's operands, that is we only reduce the demanded bits for those instructions that are always truncation friendly, such as ADD or SUB.

Dec 21 2020, 1:07 AM · Restricted Project
guopeilin added reviewers for D93617: [LoopVectorize] Take non-instruction's size into consideration when computing leader's demanded bits: jevinskie, wwei, jmolloy, nikic, mssimpso, danielcdh.
Dec 21 2020, 1:03 AM · Restricted Project
guopeilin added a comment to D93617: [LoopVectorize] Take non-instruction's size into consideration when computing leader's demanded bits.

So as the avoid-truncate-shift-operands.ll, before loop vectorize, we do a shift operation and then truncate its result into 8 bits. That is

%0 = lshr i32 %f, 18
%conv7 = trunc i32 %0 to i8

And the demanded bits says that we only need 8 bits of %0, so function truncateToMinimalBitwidths() firstly truncate lshr's operands into 8 bits first, and then shift, which will cause a wrong result.

%20 = trunc <2 x i32> %broadcast.splat7 to <2 x i8>
%21 = lshr <2 x i8> %20, <i8 18, i8 18>
%22 = zext <2 x i8> %21 to <2 x i32>
%23 = trunc <2 x i32> %22 to <2 x i8>
Dec 21 2020, 12:54 AM · Restricted Project
guopeilin added a comment to D93617: [LoopVectorize] Take non-instruction's size into consideration when computing leader's demanded bits.

Is this supposed to be a correctness fix, or a profitability heuristic?

I guess it is a profitability heuristic.

Dec 21 2020, 12:47 AM · Restricted Project
guopeilin added a comment to D93617: [LoopVectorize] Take non-instruction's size into consideration when computing leader's demanded bits.

Firstly, let's take avoid-truncate-icmp-operands.ll as an example to explain this patch.<br>
Before running loop vectorize pass, we can see that in the basic block if.then,

%cmp.i = icmp ult i64 %e, %d
%.sroa.speculated = select i1 %cmp.i, i64 %d, i64 %e
%conv32 = trunc i64 %.sroa.speculated to i16

we compare value d and value e, and select one of them based on the comparison. And finally truncate the result into 16-bits. <br>
However after loop vectorize pass, we wrongly truncate instruction icmp's operands firstly,

%3 = trunc <2 x i64> %broadcast.splat to <2 x i16>
%4 = trunc <2 x i64> %broadcast.splat4 to <2 x i16>
%5 = icmp ult <2 x i16> %3, %4
%6 = trunc <2 x i64> %broadcast.splat4 to <2 x i16>
%7 = trunc <2 x i64> %broadcast.splat to <2 x i16>
%8 = select <2 x i1> %5, <2 x i16> %6, <2 x i16> %7
%9 = zext <2 x i16> %8 to <2 x i64>
%10 = trunc <2 x i64> %9 to <2 x i16>

That is we only compare the lower 16 bits of value d and value e, which will cause the wrong answer because lower bits cannot represent a comparison of the whole bits.<br>
And the mechanism that how llvm truncate and zext an instruction's operands is introduced in this patch https://reviews.llvm.org/rL250032. Within this patch, it will firstly compute an instruction's MinBWs by function computeMinimumValueSizes() and then`truncateToMinimalBitwidths()`. And MinBWs comes from llvm::computeMinimumValueSizes() which uses DemandedBits analysis as one of the info source. <br>
I guess the root reason is that, during the demanded-bits computation, because the final result will be truncate into 16-bits, that is %conv32 = trunc i64 %.sroa.speculated to i16, and the llvm blindly says that the operands of instruction Trunc have the same live bits as the trunc instruction itself. So the demanded-bits of raw instruction %.sroa.speculated = select i1 %cmp.i, i64 %d, i64 %e is 16-bits too. <br>
And during truncateToMinimalBitwidths, llvm will truncate operands first.

Dec 21 2020, 12:31 AM · Restricted Project
guopeilin requested review of D93617: [LoopVectorize] Take non-instruction's size into consideration when computing leader's demanded bits.
Dec 21 2020, 12:10 AM · Restricted Project

Dec 5 2020

guopeilin added a comment to D91512: [AArch64][Isel] Avoid implicit zext for SIGN_EXTEND_INREG ( TRUNCATE ).

aarch64-avoid-implicit-zext-for-SIGN_EXTEND_INREG.ll - please can you avoid using capital letters? Every so often it causes problems on windows dev machines.... (TBH its been better since the git transition).

Dec 5 2020, 1:23 AM · Restricted Project

Nov 26 2020

guopeilin updated the diff for D91512: [AArch64][Isel] Avoid implicit zext for SIGN_EXTEND_INREG ( TRUNCATE ).
Nov 26 2020, 5:20 PM · Restricted Project

Nov 25 2020

guopeilin added inline comments to D91512: [AArch64][Isel] Avoid implicit zext for SIGN_EXTEND_INREG ( TRUNCATE ).
Nov 25 2020, 5:18 PM · Restricted Project

Nov 24 2020

guopeilin updated the diff for D91512: [AArch64][Isel] Avoid implicit zext for SIGN_EXTEND_INREG ( TRUNCATE ).
Nov 24 2020, 12:26 AM · Restricted Project

Nov 20 2020

guopeilin added inline comments to D91512: [AArch64][Isel] Avoid implicit zext for SIGN_EXTEND_INREG ( TRUNCATE ).
Nov 20 2020, 2:14 AM · Restricted Project
guopeilin added inline comments to D91512: [AArch64][Isel] Avoid implicit zext for SIGN_EXTEND_INREG ( TRUNCATE ).
Nov 20 2020, 12:52 AM · Restricted Project

Nov 19 2020

guopeilin added a comment to D91513: [DeadMachineInstrctionElim] Post order visit all blocks and Iteratively run DeadMachineInstructionElim pass until nothing dead.

Do you have permission to commit?

Nov 19 2020, 10:12 PM · Restricted Project

Nov 18 2020

guopeilin added a comment to D91513: [DeadMachineInstrctionElim] Post order visit all blocks and Iteratively run DeadMachineInstructionElim pass until nothing dead.

Using post-order is quite straight-forward and only involves several lines of change. Please check the attachment.

That test passed with this traverse order change.

That's a great help, I pass all my related cases with this patch, Thanks a lot.

Now that we decide to use post order to visit all blocks of a function, I think we need to consider that what if CFG contains cycles?


From this picture, we can see that post order is not clearly defined cause there exits cycles, one of the possible orders is that [ m, g, d, e, c, b, t, x]
So m comes before g, if we define something in m and use it in g. Then even though both def and use are useless, cause we visit m first, we will still get a dead definition after we post-order visit all blocks.
So is it possible there still exist some cases theoretically that cannot be fixed by post-order visit? That is we may still need to iteratively run?

You are right, that's possible. That case should be rare as that's a def in the back-edge with acyclic dep. Could you merge the post-order change together with the iterative runs? so that, in the regular case, we at most run twice. Please keep on eye on compile time.

Nov 18 2020, 1:42 AM · Restricted Project
guopeilin updated the diff for D91513: [DeadMachineInstrctionElim] Post order visit all blocks and Iteratively run DeadMachineInstructionElim pass until nothing dead.
Nov 18 2020, 1:41 AM · Restricted Project

Nov 17 2020

guopeilin updated the diff for D91325: [IndVarSimplify] Notify top most loop to drop cached exit counts.
Nov 17 2020, 10:02 PM · Restricted Project
guopeilin added a comment to D91513: [DeadMachineInstrctionElim] Post order visit all blocks and Iteratively run DeadMachineInstructionElim pass until nothing dead.

Using post-order is quite straight-forward and only involves several lines of change. Please check the attachment.

That test passed with this traverse order change.

That's a great help, I pass all my related cases with this patch, Thanks a lot.

Nov 17 2020, 6:29 PM · Restricted Project
guopeilin added a comment to D91513: [DeadMachineInstrctionElim] Post order visit all blocks and Iteratively run DeadMachineInstructionElim pass until nothing dead.

Using post-order is quite straight-forward and only involves several lines of change. Please check the attachment.

That test passed with this traverse order change.

Nov 17 2020, 6:22 PM · Restricted Project

Nov 16 2020

guopeilin added a comment to D91325: [IndVarSimplify] Notify top most loop to drop cached exit counts.

Yse, So I use forgetTopmostLoop() after optimizeLoopExits directly, I think it's more concise.

Nov 16 2020, 10:07 PM · Restricted Project
guopeilin updated the diff for D91325: [IndVarSimplify] Notify top most loop to drop cached exit counts.
Nov 16 2020, 10:04 PM · Restricted Project
guopeilin updated the diff for D91325: [IndVarSimplify] Notify top most loop to drop cached exit counts.

use forgetTopmostLoop() directly instead of visiting exitingBB among nested loops

Nov 16 2020, 8:13 PM · Restricted Project
guopeilin retitled D91513: [DeadMachineInstrctionElim] Post order visit all blocks and Iteratively run DeadMachineInstructionElim pass until nothing dead from [DeadMachineInstrctionElim] Iteratively run DeadMachineInstrcutionElim pass until nothing dead to [DeadMachineInstrctionElim] Iteratively run DeadMachineInstructionElim pass until nothing dead.
Nov 16 2020, 5:26 PM · Restricted Project
guopeilin retitled D91513: [DeadMachineInstrctionElim] Post order visit all blocks and Iteratively run DeadMachineInstructionElim pass until nothing dead from [DeadMachineInstrctionElim] Iteratively run DeadMachineInstrcutionElim pass untill nothing dead to [DeadMachineInstrctionElim] Iteratively run DeadMachineInstrcutionElim pass until nothing dead.
Nov 16 2020, 5:26 PM · Restricted Project
guopeilin added a comment to D91513: [DeadMachineInstrctionElim] Post order visit all blocks and Iteratively run DeadMachineInstructionElim pass until nothing dead.

could you elaborate more on why we need to run that iteratively? since the original one runs bottom-up, supposedly it should find all.

Nov 16 2020, 5:25 PM · Restricted Project

Nov 15 2020

guopeilin added reviewers for D91513: [DeadMachineInstrctionElim] Post order visit all blocks and Iteratively run DeadMachineInstructionElim pass until nothing dead: sunfish, hliao, rampitec, wwei.
Nov 15 2020, 8:24 PM · Restricted Project
guopeilin added reviewers for D91512: [AArch64][Isel] Avoid implicit zext for SIGN_EXTEND_INREG ( TRUNCATE ): wwei, t.p.northover, paulwalker-arm, efriedma, dmgreen, samparker.
Nov 15 2020, 8:16 PM · Restricted Project
guopeilin requested review of D91513: [DeadMachineInstrctionElim] Post order visit all blocks and Iteratively run DeadMachineInstructionElim pass until nothing dead.
Nov 15 2020, 7:22 PM · Restricted Project
guopeilin requested review of D91512: [AArch64][Isel] Avoid implicit zext for SIGN_EXTEND_INREG ( TRUNCATE ).
Nov 15 2020, 7:17 PM · Restricted Project

Nov 13 2020

guopeilin added a comment to D91325: [IndVarSimplify] Notify top most loop to drop cached exit counts.

I'm not really getting how wrong cached exit count may possibly lead to hang. Could you please explain this problem more?

Nov 13 2020, 12:49 AM · Restricted Project

Nov 12 2020

guopeilin added a comment to D91325: [IndVarSimplify] Notify top most loop to drop cached exit counts.

https://bugs.llvm.org/show_bug.cgi?id=48158

Nov 12 2020, 5:31 PM · Restricted Project
guopeilin added reviewers for D91325: [IndVarSimplify] Notify top most loop to drop cached exit counts: reames, apilipenko, ebrevnov.
Nov 12 2020, 1:00 AM · Restricted Project
guopeilin requested review of D91325: [IndVarSimplify] Notify top most loop to drop cached exit counts.
Nov 12 2020, 12:49 AM · Restricted Project