Page MenuHomePhabricator

congzhe (Congzhe Cao)
User

Projects

User does not belong to any projects.

User Details

User Since
Jan 2 2020, 7:36 AM (67 w, 2 d)

Recent Activity

Thu, Apr 8

congzhe committed rGce2db9005d70: [LoopInterchange] Fix transformation bugs in loop interchange (authored by congzhe).
[LoopInterchange] Fix transformation bugs in loop interchange
Thu, Apr 8, 12:00 PM
congzhe closed D98475: [LoopInterchange] Fix transformation bugs in loop interchange.
Thu, Apr 8, 11:59 AM · Restricted Project
congzhe reopened D98475: [LoopInterchange] Fix transformation bugs in loop interchange.
Thu, Apr 8, 8:55 AM · Restricted Project
congzhe added a comment to D98475: [LoopInterchange] Fix transformation bugs in loop interchange.

I committed and reverted the patch since it fails x86 sanitizer check. The reason is that after the patch, the variable LoopExit becomes unused.

Thu, Apr 8, 8:54 AM · Restricted Project
congzhe updated the diff for D98475: [LoopInterchange] Fix transformation bugs in loop interchange.

Removed the variable LoopExit.

Thu, Apr 8, 8:51 AM · Restricted Project

Wed, Apr 7

congzhe committed rG593cb4655097: Revert "[LoopInterchange] Fix transformation bugs in loop interchange" (authored by congzhe).
Revert "[LoopInterchange] Fix transformation bugs in loop interchange"
Wed, Apr 7, 6:18 PM
congzhe committed rGf5645ea65f0d: [LoopInterchange] Fix transformation bugs in loop interchange (authored by congzhe).
[LoopInterchange] Fix transformation bugs in loop interchange
Wed, Apr 7, 5:57 PM
congzhe closed D98475: [LoopInterchange] Fix transformation bugs in loop interchange.
Wed, Apr 7, 5:57 PM · Restricted Project
congzhe added a comment to D98475: [LoopInterchange] Fix transformation bugs in loop interchange.

Thanks for fixing this problem. I just have some comments about the tests, otherwise LGTM.

Wed, Apr 7, 9:38 AM · Restricted Project
congzhe updated the diff for D98475: [LoopInterchange] Fix transformation bugs in loop interchange.

All comments addressed.

Wed, Apr 7, 9:36 AM · Restricted Project

Tue, Apr 6

congzhe updated the diff for D98475: [LoopInterchange] Fix transformation bugs in loop interchange.

Removed unnecessary code, simplified the logic.

Tue, Apr 6, 10:08 AM · Restricted Project
congzhe added a comment to D98475: [LoopInterchange] Fix transformation bugs in loop interchange.
Tue, Apr 6, 8:27 AM · Restricted Project

Sun, Mar 28

congzhe added a comment to D98475: [LoopInterchange] Fix transformation bugs in loop interchange.

gentle ping @fhahn @Whitney @bmahjour

Sun, Mar 28, 3:06 PM · Restricted Project

Fri, Mar 26

congzhe added a reviewer for D98475: [LoopInterchange] Fix transformation bugs in loop interchange: bmahjour.
Fri, Mar 26, 1:09 PM · Restricted Project

Wed, Mar 24

congzhe committed rG829c1b644390: [LoopInterchange] fix tightlyNested() in LoopInterchange legality (authored by congzhe).
[LoopInterchange] fix tightlyNested() in LoopInterchange legality
Wed, Mar 24, 12:50 PM
congzhe closed D98263: [LoopInterchange] fix tightlyNested() in LoopInterchange legality.
Wed, Mar 24, 12:50 PM · Restricted Project

Tue, Mar 23

congzhe added a comment to D98263: [LoopInterchange] fix tightlyNested() in LoopInterchange legality.

I am fine with this change now, but in the future we should try to

  1. Use utilities in LoopNest as much as possible
  2. Loosen the definition perfect loop nest in LoopNest
  3. Make the transformation more generic to handle more cases, e.g. the newly added test interchange_07.
Tue, Mar 23, 7:12 PM · Restricted Project
congzhe updated the diff for D98263: [LoopInterchange] fix tightlyNested() in LoopInterchange legality.

Updated the patch according to the comments.

Tue, Mar 23, 7:08 PM · Restricted Project
congzhe added a comment to D98475: [LoopInterchange] Fix transformation bugs in loop interchange.

gentle ping @fhahn @Whitney

Tue, Mar 23, 1:47 AM · Restricted Project
congzhe added a comment to D98263: [LoopInterchange] fix tightlyNested() in LoopInterchange legality.

gentle ping @fhahn @Whitney

Tue, Mar 23, 1:47 AM · Restricted Project

Mar 17 2021

congzhe added a comment to D98475: [LoopInterchange] Fix transformation bugs in loop interchange.

gentle ping @fhahn @Whitney

Mar 17 2021, 1:29 AM · Restricted Project
congzhe added a comment to D98263: [LoopInterchange] fix tightlyNested() in LoopInterchange legality.

gentle ping @fhahn @Whitney

Mar 17 2021, 1:28 AM · Restricted Project

Mar 11 2021

congzhe updated the summary of D98475: [LoopInterchange] Fix transformation bugs in loop interchange.
Mar 11 2021, 8:10 PM · Restricted Project
congzhe requested review of D98475: [LoopInterchange] Fix transformation bugs in loop interchange.
Mar 11 2021, 8:09 PM · Restricted Project

Mar 10 2021

congzhe added a comment to D98263: [LoopInterchange] fix tightlyNested() in LoopInterchange legality.

Hi @congzhe, thanks for the fix!

I think it'd probably be better to keep the LoopNest::checkLoopsStructure and add the additional checks of branch instructions for now.
By doing so, future changes to LoopNest will also apply in LoopInterchange, which is what we are trying to achieve I think (by making the definition of perfectly-nested loop in sync).
The check can be removed in the future, when LoopNest is eventually taught to correctly identify guard branches (singleSucc is currently considered to be the guard branch of the inner loop, but the loops should only be considered perfectly-nested if the guard branch corresponds to the one added by LoopRotate IMO, which is not true in this case).

What do you think?

Mar 10 2021, 10:51 PM · Restricted Project
congzhe added a comment to D98263: [LoopInterchange] fix tightlyNested() in LoopInterchange legality.

The patch now revert part of https://reviews.llvm.org/rGdf9158c9a45a6902c2b0394f9bd6512e3e441f31, which leave some changes behind.
Given that the change cause a test case crash, @TaWeiTu can you please revert the change?

Sure, reverted.

Mar 10 2021, 6:44 PM · Restricted Project
congzhe updated the diff for D98263: [LoopInterchange] fix tightlyNested() in LoopInterchange legality.

Updated the patch based on the latest trunk code.

Mar 10 2021, 6:41 PM · Restricted Project
congzhe added a comment to D98263: [LoopInterchange] fix tightlyNested() in LoopInterchange legality.

Thanks for fixing it. Is the crashing test case an existing test case, or will be added in D96708 or D91682? If not, can you please also include that test case in this patch?

Mar 10 2021, 9:10 AM · Restricted Project
congzhe updated the diff for D98263: [LoopInterchange] fix tightlyNested() in LoopInterchange legality.

Updated the patch.

Mar 10 2021, 9:06 AM · Restricted Project

Mar 9 2021

congzhe updated the summary of D98263: [LoopInterchange] fix tightlyNested() in LoopInterchange legality.
Mar 9 2021, 10:16 PM · Restricted Project
congzhe added a comment to D98263: [LoopInterchange] fix tightlyNested() in LoopInterchange legality.

An update: the current trunk code (without this patch) fails the following test (crashes as follows):

Mar 9 2021, 9:54 PM · Restricted Project
congzhe added a comment to D96708: [llvm] Bug fix: tightlyNested() of Loop interchange.

I added some comments to the source code.

Mar 9 2021, 1:18 PM · Restricted Project
congzhe updated the diff for D98263: [LoopInterchange] fix tightlyNested() in LoopInterchange legality.
Mar 9 2021, 8:00 AM · Restricted Project
congzhe updated the summary of D98263: [LoopInterchange] fix tightlyNested() in LoopInterchange legality.
Mar 9 2021, 7:45 AM · Restricted Project
congzhe updated the summary of D98263: [LoopInterchange] fix tightlyNested() in LoopInterchange legality.
Mar 9 2021, 7:45 AM · Restricted Project
congzhe updated the summary of D98263: [LoopInterchange] fix tightlyNested() in LoopInterchange legality.
Mar 9 2021, 7:44 AM · Restricted Project
congzhe updated the summary of D98263: [LoopInterchange] fix tightlyNested() in LoopInterchange legality.
Mar 9 2021, 7:43 AM · Restricted Project
congzhe updated the summary of D98263: [LoopInterchange] fix tightlyNested() in LoopInterchange legality.
Mar 9 2021, 7:34 AM · Restricted Project
congzhe updated the summary of D98263: [LoopInterchange] fix tightlyNested() in LoopInterchange legality.
Mar 9 2021, 7:34 AM · Restricted Project
congzhe updated the summary of D98263: [LoopInterchange] fix tightlyNested() in LoopInterchange legality.
Mar 9 2021, 7:33 AM · Restricted Project
congzhe requested review of D98263: [LoopInterchange] fix tightlyNested() in LoopInterchange legality.
Mar 9 2021, 7:24 AM · Restricted Project

Feb 25 2021

congzhe added inline comments to D96708: [llvm] Bug fix: tightlyNested() of Loop interchange.
Feb 25 2021, 9:49 PM · Restricted Project

Dec 31 2020

congzhe added a comment to D93065: [InstCombine] Disable optimizations of select instructions that causes propagation of poison values.

Okay, I think the remaining optimizations (other than opened patches) are:

  • LoopUnswitch.cpp: I can address this
  • PredicateInfo.cpp: I'm not sure whether a local change will be enough, because the relevant classes in PredicateInfo.h are exposed to other optimizations.
  • SimpleLoopUnswitch.cpp, LoopPredication.cpp, InductiveRangeCheckElimination.cpp: have no idea

After LoopUnswitch and PredicateInfo is updated & the select -> and/or is conditionally allowed, we can try performance evaluation again and see whether there still exists regression. What do you think? @nikic @congzhe

Dec 31 2020, 8:16 AM · Restricted Project, Restricted Project

Dec 21 2020

congzhe added a comment to D93272: [InstCombine] Add checking of i1 types when converting select instructions into zext/sext instructions.

LGTM

Dec 21 2020, 3:50 PM · Restricted Project, Restricted Project
congzhe committed rGc60a58f8d435: [InstCombine] Add check of i1 types in select-to-zext/sext transformation (authored by congzhe).
[InstCombine] Add check of i1 types in select-to-zext/sext transformation
Dec 21 2020, 3:48 PM
congzhe closed D93272: [InstCombine] Add checking of i1 types when converting select instructions into zext/sext instructions.
Dec 21 2020, 3:48 PM · Restricted Project, Restricted Project
congzhe updated the diff for D93272: [InstCombine] Add checking of i1 types when converting select instructions into zext/sext instructions.
Dec 21 2020, 10:29 AM · Restricted Project, Restricted Project
congzhe updated the diff for D93272: [InstCombine] Add checking of i1 types when converting select instructions into zext/sext instructions.
Dec 21 2020, 10:28 AM · Restricted Project, Restricted Project

Dec 20 2020

congzhe added a comment to D93065: [InstCombine] Disable optimizations of select instructions that causes propagation of poison values.

Using freeze loses information (if some of the inputs was poison). Plus It requires an extra op.
If we canonicalize around select there's no loss of information and it's just 1 instruction.

The disadvantage is that then we have 2 ways or doing boolean ANDs/ORs. Though most analyses can be patched easily, as most LLVM analyses' results are of the form "x has property foo unless it's poison". So for those analyses using and/or or select is the same (as the only difference between these is propagation of poison).
Other analyses/optimization can learn about select as needed.

Thank you for raising up the good point! I understand that we lose information by preventing poison values from propagation using freeze. But I'm unclear what would be the side effect or problem with that? I'd appreciate it if you could clarify a bit, thanks!

In practice, probably not a lot. But it may have implications for loop optimization, like:

for (i=0; some_bool && i < limit; ++i) {
...
}

If you remove the poison from the i+1 < limit bit it may make the work of SCEV harder (or impossible; didn't think the example through carefully).

Dec 20 2020, 12:40 PM · Restricted Project, Restricted Project

Dec 18 2020

congzhe committed rG06d5b1c9ad52: [SROA] Remove Dead Instructions while creating speculative instructions (authored by Arnamoy Bhattacharyya <arnamoy.bhattacharyya@huawei.com>).
[SROA] Remove Dead Instructions while creating speculative instructions
Dec 18 2020, 8:49 AM
congzhe closed D92431: [SROA] Remove Dead Instructions while creating speculative instructions.
Dec 18 2020, 8:49 AM · Restricted Project

Dec 17 2020

congzhe added a comment to D93065: [InstCombine] Disable optimizations of select instructions that causes propagation of poison values.

Using freeze loses information (if some of the inputs was poison). Plus It requires an extra op.
If we canonicalize around select there's no loss of information and it's just 1 instruction.

The disadvantage is that then we have 2 ways or doing boolean ANDs/ORs. Though most analyses can be patched easily, as most LLVM analyses' results are of the form "x has property foo unless it's poison". So for those analyses using and/or or select is the same (as the only difference between these is propagation of poison).
Other analyses/optimization can learn about select as needed.

Dec 17 2020, 2:05 PM · Restricted Project, Restricted Project
congzhe added a comment to D93065: [InstCombine] Disable optimizations of select instructions that causes propagation of poison values.

This will require other parts of the compiler (especially anything dealing with and/or'd branch conditions, like SCEV, LVI, ValueTracking etc) to understand this new form of and/or first. I don't think most optimizations care about whether and/or is poison-blocking or not, but they need to recognize the select form if we don't canonicalize.

Thank you, I do agree with you that some infrastructures like SCEV might be impacted. Could you clarify it a bit? I am working on unit tests and perf degradation. Should the cause of any of them be those infrastructures, I will post fixes. Would that address your concern? Or something more than that is needed?"

Thanks Sanjay, by "perf data" I'm wondering which benchmarks does the community mostly care about? LLVM test-suite?

We would get a different answer for each person/company, but test-suite is solid common ground. I think SPEC is also widely used by a large part of the community.

As you said there's two ways to address this bug -- one is this patch, the other is inserting freezes. With this patch I do see degradations on some internal benchmarks and I'm working on the fix. Do you think it is the right track? I just would like to make sure before going too far.

The work I do is on AArch64. It may or may not impact other architectures (X86, PowerPC, etc). I'm wondering what is the typical way in the community to address performance degradations since addressing degradations for all possible architectures seems significant amount of work hence not likely?

In general, we try to address known regressions in advance. If you see a problem on AArch64, it will probably not be too different for the other CPU targets.
It is acknowledged that it is impossible to know how a change like this will affect everything, so as long as we have a plan to deal with problems, it's fine to proceed.
My suggestion is to compare the regressions between this patch vs. adding freeze on test-suite. Is there a clear winner (number and average size of regressions)?
Thank you for pushing this forward!

Dec 17 2020, 9:11 AM · Restricted Project, Restricted Project

Dec 15 2020

congzhe updated the diff for D93272: [InstCombine] Add checking of i1 types when converting select instructions into zext/sext instructions.
Dec 15 2020, 2:59 PM · Restricted Project, Restricted Project

Dec 14 2020

congzhe requested review of D93272: [InstCombine] Add checking of i1 types when converting select instructions into zext/sext instructions.
Dec 14 2020, 9:18 PM · Restricted Project, Restricted Project
congzhe added inline comments to D93065: [InstCombine] Disable optimizations of select instructions that causes propagation of poison values.
Dec 14 2020, 1:37 PM · Restricted Project, Restricted Project
congzhe updated the diff for D93065: [InstCombine] Disable optimizations of select instructions that causes propagation of poison values.
Dec 14 2020, 1:36 PM · Restricted Project, Restricted Project
congzhe added a comment to D93065: [InstCombine] Disable optimizations of select instructions that causes propagation of poison values.

Current failing regression tests:

Dec 14 2020, 1:18 PM · Restricted Project, Restricted Project
congzhe added a comment to D93065: [InstCombine] Disable optimizations of select instructions that causes propagation of poison values.

This will require other parts of the compiler (especially anything dealing with and/or'd branch conditions, like SCEV, LVI, ValueTracking etc) to understand this new form of and/or first. I don't think most optimizations care about whether and/or is poison-blocking or not, but they need to recognize the select form if we don't canonicalize.

Dec 14 2020, 1:15 PM · Restricted Project, Restricted Project
congzhe added a comment to D93065: [InstCombine] Disable optimizations of select instructions that causes propagation of poison values.

Performance data? No regressions for benchmarks?

Dec 14 2020, 10:10 AM · Restricted Project, Restricted Project

Dec 11 2020

congzhe added inline comments to D93065: [InstCombine] Disable optimizations of select instructions that causes propagation of poison values.
Dec 11 2020, 8:58 PM · Restricted Project, Restricted Project
congzhe updated the diff for D93065: [InstCombine] Disable optimizations of select instructions that causes propagation of poison values.

Updated to address comments.

Dec 11 2020, 8:56 PM · Restricted Project, Restricted Project

Dec 10 2020

congzhe updated the summary of D93065: [InstCombine] Disable optimizations of select instructions that causes propagation of poison values.
Dec 10 2020, 1:29 PM · Restricted Project, Restricted Project
congzhe updated the summary of D93065: [InstCombine] Disable optimizations of select instructions that causes propagation of poison values.
Dec 10 2020, 1:28 PM · Restricted Project, Restricted Project
congzhe requested review of D93065: [InstCombine] Disable optimizations of select instructions that causes propagation of poison values.
Dec 10 2020, 1:24 PM · Restricted Project, Restricted Project

Sep 30 2020

congzhe updated the diff for D86956: [AArch64] Avoid pairing loads when the base reg is modified.
Sep 30 2020, 8:55 AM · Restricted Project, Restricted Project, Restricted Project
congzhe updated the diff for D86956: [AArch64] Avoid pairing loads when the base reg is modified.
Sep 30 2020, 8:50 AM · Restricted Project, Restricted Project, Restricted Project
congzhe added a comment to D86956: [AArch64] Avoid pairing loads when the base reg is modified.

Thanks for all the comments, now addressed all of them @fhahn

Sep 30 2020, 7:23 AM · Restricted Project, Restricted Project, Restricted Project
congzhe updated the diff for D86956: [AArch64] Avoid pairing loads when the base reg is modified.
Sep 30 2020, 7:20 AM · Restricted Project, Restricted Project, Restricted Project

Sep 29 2020

congzhe added a comment to D86956: [AArch64] Avoid pairing loads when the base reg is modified.

@fhahn pinging reviewers :)
Comments are very much appreciated.

Sep 29 2020, 9:44 PM · Restricted Project, Restricted Project, Restricted Project

Sep 20 2020

congzhe added inline comments to D86956: [AArch64] Avoid pairing loads when the base reg is modified.
Sep 20 2020, 9:28 PM · Restricted Project, Restricted Project, Restricted Project
congzhe updated the diff for D86956: [AArch64] Avoid pairing loads when the base reg is modified.
Sep 20 2020, 9:11 PM · Restricted Project, Restricted Project, Restricted Project
congzhe updated the diff for D86906: [AArch64] Avoid pairing loads with same result reg.
Sep 20 2020, 9:11 PM · Restricted Project, Restricted Project, Restricted Project

Sep 18 2020

congzhe added a comment to D86906: [AArch64] Avoid pairing loads with same result reg.

oh, it might be good to slightly adjust the commit message to be a bit more compact and also mention what actual bug is fixed, e.g. something like [AArch64] Avoid paring loads with same result reg.

Sep 18 2020, 11:45 AM · Restricted Project, Restricted Project, Restricted Project

Sep 17 2020

congzhe retitled D86956: [AArch64] Avoid pairing loads when the base reg is modified from [AArch64LoadStoreOptimization] Bug fix in ldr to ldp conversion to [AArch64] Avoid pairing loads when the base reg is modified.
Sep 17 2020, 3:58 PM · Restricted Project, Restricted Project, Restricted Project
congzhe retitled D86906: [AArch64] Avoid pairing loads with same result reg from [AArch64LdStOptimzation] fix a bug in AArch64 Load Store Optimization to [AArch64] Avoid pairing loads with same result reg.
Sep 17 2020, 3:50 PM · Restricted Project, Restricted Project, Restricted Project
congzhe added inline comments to D86906: [AArch64] Avoid pairing loads with same result reg.
Sep 17 2020, 4:29 AM · Restricted Project, Restricted Project, Restricted Project
congzhe updated the diff for D86956: [AArch64] Avoid pairing loads when the base reg is modified.
Sep 17 2020, 4:28 AM · Restricted Project, Restricted Project, Restricted Project
congzhe added inline comments to D86906: [AArch64] Avoid pairing loads with same result reg.
Sep 17 2020, 4:27 AM · Restricted Project, Restricted Project, Restricted Project
congzhe updated the diff for D86906: [AArch64] Avoid pairing loads with same result reg.
Sep 17 2020, 4:26 AM · Restricted Project, Restricted Project, Restricted Project

Sep 16 2020

congzhe updated the diff for D86956: [AArch64] Avoid pairing loads when the base reg is modified.
Sep 16 2020, 3:10 PM · Restricted Project, Restricted Project, Restricted Project
congzhe added a comment to D86956: [AArch64] Avoid pairing loads when the base reg is modified.

Further reduced the mir test case.

Sep 16 2020, 12:25 PM · Restricted Project, Restricted Project, Restricted Project
congzhe added inline comments to D86906: [AArch64] Avoid pairing loads with same result reg.
Sep 16 2020, 12:24 PM · Restricted Project, Restricted Project, Restricted Project
congzhe updated the diff for D86956: [AArch64] Avoid pairing loads when the base reg is modified.
Sep 16 2020, 12:22 PM · Restricted Project, Restricted Project, Restricted Project
congzhe updated the diff for D86906: [AArch64] Avoid pairing loads with same result reg.
Sep 16 2020, 12:21 PM · Restricted Project, Restricted Project, Restricted Project

Sep 10 2020

congzhe added a comment to D86956: [AArch64] Avoid pairing loads when the base reg is modified.

Is it possible to add a MIR test for the issue? Also, it looks like the formatting is off a bit. Could you run clang-format-diff on the change?

Sep 10 2020, 2:49 PM · Restricted Project, Restricted Project, Restricted Project
congzhe updated the diff for D86956: [AArch64] Avoid pairing loads when the base reg is modified.

Revision:

  • Fixed code style
  • Provided an mir test
Sep 10 2020, 2:47 PM · Restricted Project, Restricted Project, Restricted Project
congzhe added inline comments to D86906: [AArch64] Avoid pairing loads with same result reg.
Sep 10 2020, 2:45 PM · Restricted Project, Restricted Project, Restricted Project
congzhe updated the diff for D86906: [AArch64] Avoid pairing loads with same result reg.

Revision:

  • Fixed code style
  • Reduce the length of the test file
Sep 10 2020, 2:39 PM · Restricted Project, Restricted Project, Restricted Project

Sep 2 2020

congzhe updated the diff for D84220: [IPSCCP] Fix a bug that the "returned" attribute is not cleared when function is optimized to return undef.
Sep 2 2020, 7:56 AM · Restricted Project, Restricted Project

Sep 1 2020

congzhe added a comment to D84220: [IPSCCP] Fix a bug that the "returned" attribute is not cleared when function is optimized to return undef.

rebased and clang format-ed the code, ready to merge

great, thanks! As mentioned earlier, please let us know here if you need someone to commit this change on your behalf, with the name/email you'd like the author field set to.

Sep 1 2020, 11:58 AM · Restricted Project, Restricted Project
congzhe updated the diff for D84220: [IPSCCP] Fix a bug that the "returned" attribute is not cleared when function is optimized to return undef.

rebased and clang format-ed the code, ready to merge

Sep 1 2020, 11:23 AM · Restricted Project, Restricted Project
congzhe added a comment to D86956: [AArch64] Avoid pairing loads when the base reg is modified.

Is it possible to add a MIR test for the issue? Also, it looks like the formatting is off a bit. Could you run clang-format-diff on the change?

Sep 1 2020, 9:59 AM · Restricted Project, Restricted Project, Restricted Project
congzhe added inline comments to D86906: [AArch64] Avoid pairing loads with same result reg.
Sep 1 2020, 9:49 AM · Restricted Project, Restricted Project, Restricted Project
congzhe requested review of D86956: [AArch64] Avoid pairing loads when the base reg is modified.
Sep 1 2020, 9:39 AM · Restricted Project, Restricted Project, Restricted Project

Aug 31 2020

congzhe requested review of D86906: [AArch64] Avoid pairing loads with same result reg.
Aug 31 2020, 9:34 PM · Restricted Project, Restricted Project, Restricted Project

Aug 28 2020

congzhe added a comment to D84220: [IPSCCP] Fix a bug that the "returned" attribute is not cleared when function is optimized to return undef.

@fhahn Thanks for the comments.

Aug 28 2020, 11:57 AM · Restricted Project, Restricted Project
congzhe updated the diff for D84220: [IPSCCP] Fix a bug that the "returned" attribute is not cleared when function is optimized to return undef.
Aug 28 2020, 11:56 AM · Restricted Project, Restricted Project
congzhe updated the diff for D84220: [IPSCCP] Fix a bug that the "returned" attribute is not cleared when function is optimized to return undef.
Aug 28 2020, 11:52 AM · Restricted Project, Restricted Project

Aug 27 2020

congzhe added inline comments to D84220: [IPSCCP] Fix a bug that the "returned" attribute is not cleared when function is optimized to return undef.
Aug 27 2020, 9:22 AM · Restricted Project, Restricted Project