Z: Support NaN values w.r.t fmax/fmin/dmax/dmin on S390 #7196

sarwat12 · 2023-12-06T17:42:14Z

This PR adds support to the S390 MaxMin evaluator to handle NaN operands for [fd]min/max opcodes.

Add NaN checks and set return register to NaN if either operands are NaN
Enable MaxMin tests for Float/Double on LoZ, and disable them on z/OS

Closes: #5157

Signed-off-by: Sarwat Shaheen sarwat.shaheen@yahoo.com

sarwat12 · 2023-12-06T18:00:54Z

Tagging @r30shah and @Spencer-Comin for review.

sarwat12 · 2023-12-06T18:21:57Z

Personal Build #19727 to test the changes.

r30shah · 2023-12-07T04:16:33Z

compiler/z/codegen/ControlFlowEvaluator.cpp

@@ -334,23 +334,61 @@ xmaxxminHelper(TR::Node* node, TR::CodeGenerator* cg, TR::InstOpCode::Mnemonic c

   TR::LabelSymbol* cFlowRegionStart = generateLabelSymbol(cg);
   TR::LabelSymbol* cFlowRegionEnd = generateLabelSymbol(cg);
+   //Label Symbol for handling NaN operands
+   TR::LabelSymbol* nanLabel = generateLabelSymbol(cg);


Move the initialization of nanLabel closer to where it is used.

r30shah · 2023-12-07T04:22:58Z

compiler/z/codegen/ControlFlowEvaluator.cpp


+   //Handle NaN case for doubles
+   if (node->getOpCode().isDouble())


Is this evaluator used for non floating type min max as well (integer , long , etc) ?
I believe we pass in the move Op and compare Op so it will generate appropriate instructions for such cases.

Current change in this PR would have NaN case for all the types whereas Integer / Long do not have a NaN.

Can you confirm? If this is true than, we need to refactor and add checks so that only Double and Float would generate NaN case.

Yes, you're correct, I confirm that this evaluator is also used in specific cases of int/long MaxMin calls. Since only double and float generate NaN cases, I could try refactoring out the double/float specific code to a separate helper function. Something like this at the start of xmaxxminHelper:

`

if (node->getOpCode().isDouble() || node->getOpCode().isFloat()){ return fdmaxminHelper(node, cg, compareRROp, branchCond, moveRROp); }

`

Thanks for confirming. I think you can refactor the single function to handle this scenario. You need to guard the NaN changes with isDouble/Float query. You can tackle the common condition code early on (CC 0/1/2) first and lastly you can generate code for NaN case)

@sarwat12 You still need to work on this suggestion. Evaluator in current state will allocate a register to hold NaN value for Integral type min and max node as well. Code for NaN should only be generated for float and double.

sarwat12 · 2023-12-13T19:11:31Z

Personal Build #19902 to test new changes.

sarwat12 · 2023-12-14T16:15:27Z

Tagging @r30shah for review.

r30shah

Please address the last comment.

r30shah · 2023-12-15T19:10:22Z

compiler/z/codegen/ControlFlowEvaluator.cpp

-
-   TR::RegisterDependencyConditions* deps = new (cg->trHeapMemory()) TR::RegisterDependencyConditions(0, 2, cg);
+   //Label Symbol for handling possible NaN operand case for float/double
+   TR::LabelSymbol* nanLabel;


Initialize nanLabel to NULL.

r30shah · 2023-12-15T19:13:04Z

compiler/z/codegen/ControlFlowEvaluator.cpp

+   generateS390BranchInstruction(cg, TR::InstOpCode::BRC, TR::InstOpCode::COND_BRC, node, cFlowRegionEnd);
+
+   //Handle NaN case
+   generateS390LabelInstruction(cg, TR::InstOpCode::label, node, nanLabel);


This is incorrect. We only generate nanLabel symbol for Double / Float case. nanLabel for other case would be uninitialized. This will fail while compiling.

r30shah · 2023-12-15T19:14:15Z

compiler/z/codegen/ControlFlowEvaluator.cpp

+      genLoadLongConstant(cg, node, DOUBLE_NAN, nanReg, NULL, deps, NULL);
+      generateRRInstruction(cg, TR::InstOpCode::LDGR, node, lhsReg, nanReg);
+      }
+   else


If node is not double than, it can be int, long, short, byte and float. You can not assume it will be Float only.

r30shah

Minor change, overall it is good.

r30shah · 2024-01-11T19:56:57Z

compiler/z/codegen/ControlFlowEvaluator.cpp

+         {
+         //Load immediate DOUBLE_NAN value into GPR, then move it to result FPR
+         genLoadLongConstant(cg, node, DOUBLE_NAN, nanReg, NULL, deps, NULL);
+         generateRRInstruction(cg, TR::InstOpCode::LDGR, node, lhsReg, nanReg);


This is the common instruction for both Double and Float, should move it out of if-else block

r30shah · 2024-01-11T20:14:28Z

compiler/z/codegen/ControlFlowEvaluator.cpp

+         generateRRInstruction(cg, TR::InstOpCode::LDGR, node, lhsReg, nanReg);
+         }
+      deps->addPostConditionIfNotAlreadyInserted(nanReg, TR::RealRegister::AssignAny);
+      cg->stopUsingRegister(nanReg);


Can you move this line to end of evaluator after you are attaching dependency to and of ICF label (You just added the register to dep)

r30shah

LGTM

r30shah · 2024-01-12T20:33:33Z

jenkins build zos,zlinux

r30shah · 2024-01-12T21:45:15Z

@sarwat12 seems like your changes are failing on z/OS. Can you investigate?

sarwat12 · 2024-02-01T17:21:03Z

New instructions sequence generated from running DoubleMaxMin tests:

[     0x2aa2652bad0]                          proc
 [     0x2aa2652bbd0]                          fence   Relative [ 0x2aa2647b3e0 ] BBStart <block_2> (frequency 10000)
 [     0x2aa2652c110]                          LD      FPR_0017, Parm[Parm  0<parm 0 D>] ?+0(GPR15)
 [     0x2aa2654a4a0]                          LD      FPR_0019, Parm[Parm  1<parm 1 D>] ?+8(GPR15)
 [     0x2aa2654a610]                          Label L0016:     # (Start of internal control flow)
 [     0x2aa2654a6d0]                          CDBR    FPR_0017,FPR_0019
 [     0x2aa2654a780]                          BRC     BLR(0x2), Label L0017
 [     0x2aa2654a840]                          LTDBR   FPR_0017,FPR_0017
 [     0x2aa2654a8f0]                          BRC     MASK2(0x1), Label L0017
 [     0x2aa2654a9b0]                          LDR     FPR_0017,FPR_0019
 [     0x2aa2654b090]                          assocreg
 [     0x2aa2654aaf0]                          Label L0017:     # (End of internal control flow)
 POST:
 {AssignAny:FPR_0017:R} {AssignAny:FPR_0019:R}
 [     0x2aa2654b7a0]                          assocreg
 [     0x2aa2654b1f0]                          retn
 POST:
 {FPR0:FPR_0017:R}
 [     0x2aa2654bd20]                          fence   Relative [ 0x2aa2647b3e4 ] BBEnd </block_2>
 [     0x2aa2654c2d0]                          assocreg {FPR0:FPR_0017:R}

New instructions sequence generated from running FloatMaxMin tests:

[     0x2aa2c4baa70]                          proc
 [     0x2aa2c4bab70]                          fence   Relative [ 0x2aa2c47b460 ] BBStart <block_2> (frequency 10000)
 [     0x2aa2c4bb0b0]                          LDE     FPR_0017, Parm[Parm  0<parm 0 F>] ?+0(GPR15),0
 [     0x2aa2c50c160]                          LDE     FPR_0019, Parm[Parm  1<parm 1 F>] ?+8(GPR15),0
 [     0x2aa2c50c2d0]                          Label L0016:     # (Start of internal control flow)
 [     0x2aa2c50c390]                          CEBR    FPR_0017,FPR_0019
 [     0x2aa2c50c440]                          BRC     BLR(0x2), Label L0017
 [     0x2aa2c50c500]                          LTEBR   FPR_0017,FPR_0017
 [     0x2aa2c50c5b0]                          BRC     MASK2(0x1), Label L0017
 [     0x2aa2c50c670]                          LER     FPR_0017,FPR_0019
 [     0x2aa2c50cd50]                          assocreg
 [     0x2aa2c50c7b0]                          Label L0017:     # (End of internal control flow)
 POST:
 {AssignAny:FPR_0017:R} {AssignAny:FPR_0019:R}
 [     0x2aa2c50d460]                          assocreg
 [     0x2aa2c50ceb0]                          retn
 POST:
 {FPR0:FPR_0017:R}
 [     0x2aa2c50d9e0]                          fence   Relative [ 0x2aa2c47b464 ] BBEnd </block_2>
 [     0x2aa2c50df90]                          assocreg {FPR0:FPR_0017:R}

r30shah · 2024-02-01T19:13:03Z

@sarwat12 Is the above instruction generated for Min or Max ? Looking at the branch after CEBR, it is Max.

sarwat12 · 2024-02-01T21:35:39Z

Hi @r30shah , I was trying to take a look at the fminEvaluator which makes a call to xmaxxminHelper. It seems that fmin passes the branch condition BLR. The above instruction sequence could be for Min.

TR::Register*
OMR::Z::TreeEvaluator::fminEvaluator(TR::Node* node, TR::CodeGenerator* cg)
   {
   return xmaxxminHelper(node, cg, TR::InstOpCode::CEBR, TR::InstOpCode::COND_BLR, TR::InstOpCode::LER);
   }

In the example case above, assuming if it is a call coming from the fminEvaluator,

CEBR    FPR_0017,FPR_0019 // First Operand low, so CC1 will be set
BRC     BLR(0x2), Label L0017 // Branch low taken to Label L0017
LTEBR   FPR_0017,FPR_0017 // This would be skipped
BRC     MASK2(0x1), Label L0017 // This would be skipped
LER     FPR_0017,FPR_0019 // This would be skipped
Label L0017: // Result Reg = FPR_0017

I could be wrong in the assumption of Min, please let me know if this seems incorrect, then I can try to verify if this may go wrong for specific corner cases.

r30shah · 2024-02-01T21:41:15Z

Can you share the binary encoding ? I want to see the CC in the encoded instruction.

sarwat12 · 2024-02-01T22:53:35Z

Binary encoding of the instructions sequence generated from running FloatMaxMin tests:

0x3ff9eb000f8 00000000 [     0x2aa24a97f20]                                                   Label L0032:
     0x3ff9eb000f8 00000000 [     0x2aa24a593a0]                                                   proc
     0x3ff9eb000f8 00000000 [     0x2aa24a98200] e3 f0 f0 78 00 24                                 STG     GPR15,#385 120(GPR15)
     0x3ff9eb000fe 00000006 [     0x2aa24a98370] e3 f0 ff 60 ff 71                                 LAY     GPR15,#386 -160(GPR15)
     0x3ff9eb00104 0000000c [     0x2aa24a98500] 70 00 f1 20                                       STE     FPR0,#387 288(GPR15)
     0x3ff9eb00108 00000010 [     0x2aa24a98670] 70 20 f1 28                                       STE     FPR2,#388 296(GPR15)
     0x3ff9eb0010c 00000014 [     0x2aa24a594a0]                                                   fence   Relative [ 0x2aa24a09f60 ] BBStart <block_2> (frequency 10000)
     0x3ff9eb0010c 00000014 [     0x2aa24a599e0] ed 00 f1 20 00 24                                 LDE     FPR0, Parm[Parm  0<parm 0 F>] 288(GPR15),0
     0x3ff9eb00112 0000001a [     0x2aa24a77d70] ed 10 f1 28 00 24                                 LDE     FPR1, Parm[Parm  1<parm 1 F>] 296(GPR15),0
     0x3ff9eb00118 00000020 [     0x2aa24a77ee0]                                                   Label L0016: # (Start of internal control flow)
     0x3ff9eb00118 00000020 [     0x2aa24a77fa0] b3 09 00 01                                       CEBR    FPR0,FPR1
     0x3ff9eb0011c 00000024 [     0x2aa24a78050] a7 24 00 25                                       BRC     BLR(0x2), Label L0017, labelTargetAddr=0x0x3ff9eb0012a
     0x3ff9eb00120 00000028 [     0x2aa24a78110] b3 02 00 00                                       LTEBR   FPR0,FPR0
     0x3ff9eb00124 0000002c [     0x2aa24a781c0] a7 14 00 20                                       BRC     MASK2(0x1), Label L0017, labelTargetAddr=0x0x3ff9eb0012a
     0x3ff9eb00128 00000030 [     0x2aa24a78280] 38 01                                             LER     FPR0,FPR1
     0x3ff9eb0012a 00000032 [     0x2aa24a783c0]                                                   Label L0017: # (End of internal control flow)
     0x3ff9eb0012a 00000032 [     0x2aa24a98780]                                                   Label L0034:
     0x3ff9eb0012a 00000032 [     0x2aa24a98900] e3 f0 f1 18 00 04                                 LG      GPR15,#389 280(GPR15)
     0x3ff9eb00130 00000038 [     0x2aa24a989b0] 07 fe                                             BCR     BER(mask=0xf), GPR14
     0x3ff9eb00132 0000003a [     0x2aa24a78ac0]                                                   retn
     0x3ff9eb00132 0000003a [     0x2aa24a795f0]                                                   fence   Relative [ 0x2aa24a09f64 ] BBEnd </block_2>
     0x3ff9eb00132 0000003a [     0x2aa24a98040]                                                   Label L0033:

r30shah · 2024-02-02T02:06:14Z

@sarwat12 Thanks for the binary encoding, I think I was bitten incorrect name printed in the instruction selection log MASK2. It is indeed MASK1 (CC3). I apologize for the confusion and have deleted the comment with misleading analysis. Posting the correct analysis here,

FPR_0017 - Op1 - < 0
FPR_0019 - Op2 - < 0
FPR_0017 < FPR_0019

CEBR    FPR_0017,FPR_0019 // First Operand low, so CC1 will be set
BRC     BLR(0x2), Label L0017 // CC1 is set not CC2 which is what BRC checks, so branch will not be taken, 
LTEBR   FPR_0017,FPR_0017 // This would be skipped
BRC     MASK2(0x1), Label L0017 // CC3 is checked which is the case when FPR_0017 is NaN, Branch will not be taken
LER     FPR_0017,FPR_0019 // FPR_0017 is loaded with FPR_0019 which is higher 
Label L0017: // Result Reg = FPR_0017

There is one modification though, I would like to suggest, It can be made in the dmax/fmax/dmin/fmin evaluator. We would not have to check for anything else if the operands are equal and can skip reg - reg load as well. Can I request you to make changes as part of this PR as well?

r30shah · 2024-02-06T20:08:19Z

compiler/z/codegen/ControlFlowEvaluator.cpp

+   if (node->getOpCode().isDouble() || node->getOpCode().isFloat())
+      {
+      if (node->getOpCode().isDouble())
+         {
+         // If first operand is NaN, then we are done, otherwise fallthrough to move second operand as result
+         generateRREInstruction(cg, TR::InstOpCode::LTDBR, node, lhsReg, lhsReg);
+         generateS390BranchInstruction(cg, TR::InstOpCode::BRC, TR::InstOpCode::COND_CC3, node, cFlowRegionEnd);
+         }
+      else if (node->getOpCode().isFloat())
+         {
+         // If first operand is NaN, then we are done, otherwise fallthrough to move second operand as result
+         generateRREInstruction(cg, TR::InstOpCode::LTEBR, node, lhsReg, lhsReg);
+         generateS390BranchInstruction(cg, TR::InstOpCode::BRC, TR::InstOpCode::COND_CC3, node, cFlowRegionEnd);
+         }
+      }


I think you can simplify the code above like following.

Suggested change

if (node->getOpCode().isDouble() || node->getOpCode().isFloat())

{

if (node->getOpCode().isDouble())

{

// If first operand is NaN, then we are done, otherwise fallthrough to move second operand as result

generateRREInstruction(cg, TR::InstOpCode::LTDBR, node, lhsReg, lhsReg);

generateS390BranchInstruction(cg, TR::InstOpCode::BRC, TR::InstOpCode::COND_CC3, node, cFlowRegionEnd);

}

else if (node->getOpCode().isFloat())

{

// If first operand is NaN, then we are done, otherwise fallthrough to move second operand as result

generateRREInstruction(cg, TR::InstOpCode::LTEBR, node, lhsReg, lhsReg);

generateS390BranchInstruction(cg, TR::InstOpCode::BRC, TR::InstOpCode::COND_CC3, node, cFlowRegionEnd);

}

}

if (node->getOpCode().isFloatingPoint())

{

// If first operand is NaN, then we are done, otherwise fallthrough to move second operand as result

generateRREInstruction(cg, node->getOpCode().isDouble() ? TR::InstOpCode::LTDBR : TR::InstOpCode::LTEBR , node, lhsReg, lhsReg);

generateS390BranchInstruction(cg, TR::InstOpCode::BRC, TR::InstOpCode::COND_CC3, node, cFlowRegionEnd);

}

r30shah · 2024-02-06T20:36:47Z

Jenkins build zos,zlinux

r30shah

One last minor nitpick. As it is just for removing comment, please wait while current builds finish before making any changes, so that we do not need to launch builds again.

r30shah · 2024-02-06T20:42:16Z

compiler/z/codegen/ControlFlowEvaluator.cpp

@@ -338,21 +338,29 @@ xmaxxminHelper(TR::Node* node, TR::CodeGenerator* cg, TR::InstOpCode::Mnemonic c
   generateS390LabelInstruction(cg, TR::InstOpCode::label, node, cFlowRegionStart);
   cFlowRegionStart->setStartInternalControlFlow();

+   //Checking common Condition Code and branching to cFlowRegionEnd


I do not see any relevance of this comment. It is checking for the condition passed into this common utility function. Pls remove it.

sarwat12 · 2024-02-06T21:15:40Z

Build for zlinux: https://ci.eclipse.org/omr/job/PullRequest-linux_390-64/4344/
Build for zos: https://ci.eclipse.org/omr/job/PullRequest-zos_390-64/4325/

r30shah

LGTM. @sarwat12 Given that we still could not get this working on z/OS (Hence could not enable the test on z/OS). Can you confirm the tests are enabled on Linux on Z?
Also please open up an issue to document what we observed on z/OS to make sure we do come back to those issues.

r30shah · 2024-02-07T15:59:13Z

@sarwat12 commit body for second commit should adhere to commit guideline

Also, Please update the commit title to reflect both facts (Enabling on LoZ and disabling on z/OS)

r30shah · 2024-02-07T16:44:47Z

Jenkins build zos,zlinux

r30shah

LGTM.

r30shah · 2024-02-07T20:50:01Z

@hzongaro Can We request you to review and merge these changes?

hzongaro

I think the changes look correct. Just a small suggestion regarding comments.

Also, the commit guidelines recommend that the title of a commit be less than 70 characters, and that each line in the body of the commit be at most 72 characters, if possible. May I ask you to adjust the comments accordingly?

Finally, as tests are still failing on z/OS, please remove the "Closes: #5157" comment.

compiler/z/codegen/ControlFlowEvaluator.cpp

- Enables the Float & Double MaxMin tests on Linux on Z - Disables them on z/OS, since TRIL parser cannot handle NaN values Closes: eclipse#5157 Signed-off-by: Sarwat Shaheen <sarwat.shaheen@yahoo.com>

Adds support to the S390 MaxMin evaluator to handle NaN operands - Check f/d operands for NaN and set return register to NaN - Avoid extra load instructions for NaN, if operands are equal Closes: eclipse#5157 Signed-off-by: Sarwat Shaheen sarwat.shaheen@yahoo.com

hzongaro

Looks good. Thanks!

hzongaro · 2024-02-14T04:15:27Z

Most recent changes only added some comments and updated commit message, so no need to rerun testing. Merging.

github-actions bot added arch:z comp:compiler comp:test comp:tril labels Dec 6, 2023

sarwat12 force-pushed the NaN_fdMinMax branch 2 times, most recently from 88d35ae to d673ff6 Compare December 6, 2023 17:54

r30shah suggested changes Dec 7, 2023

View reviewed changes

sarwat12 force-pushed the NaN_fdMinMax branch 2 times, most recently from a11dcc2 to 20f4bbd Compare December 13, 2023 19:06

sarwat12 marked this pull request as ready for review December 13, 2023 19:12

sarwat12 requested review from Leonardo2718, fjeremic and 0xdaryl as code owners December 13, 2023 19:12

r30shah suggested changes Dec 15, 2023

View reviewed changes

sarwat12 force-pushed the NaN_fdMinMax branch 2 times, most recently from 0a88bfa to 680672e Compare December 15, 2023 18:55

r30shah suggested changes Dec 15, 2023

View reviewed changes

sarwat12 force-pushed the NaN_fdMinMax branch from 680672e to 241b01f Compare December 15, 2023 20:55

sarwat12 force-pushed the NaN_fdMinMax branch from 241b01f to 63b4dbe Compare January 11, 2024 18:55

r30shah suggested changes Jan 11, 2024

View reviewed changes

sarwat12 force-pushed the NaN_fdMinMax branch 2 times, most recently from 7284904 to c1f1ce1 Compare January 12, 2024 16:06

r30shah approved these changes Jan 12, 2024

View reviewed changes

sarwat12 force-pushed the NaN_fdMinMax branch from 6f25b0b to 2a081ce Compare January 16, 2024 18:07

sarwat12 force-pushed the NaN_fdMinMax branch from 104d0d3 to 85505c0 Compare February 1, 2024 17:10

sarwat12 force-pushed the NaN_fdMinMax branch 2 times, most recently from 4f789e3 to d499cd6 Compare February 6, 2024 19:47

r30shah suggested changes Feb 6, 2024

View reviewed changes

sarwat12 force-pushed the NaN_fdMinMax branch from d499cd6 to 3144615 Compare February 6, 2024 20:27

r30shah suggested changes Feb 6, 2024

View reviewed changes

sarwat12 force-pushed the NaN_fdMinMax branch from 3144615 to 2a431ff Compare February 6, 2024 21:08

r30shah approved these changes Feb 7, 2024

View reviewed changes

sarwat12 force-pushed the NaN_fdMinMax branch from 224f918 to e25db7c Compare February 7, 2024 16:22

r30shah approved these changes Feb 7, 2024

View reviewed changes

sarwat12 mentioned this pull request Feb 7, 2024

TRIL tests on z/OS generates non-standard NaN formatting #7254

Open

hzongaro reviewed Feb 12, 2024

View reviewed changes

compiler/z/codegen/ControlFlowEvaluator.cpp Show resolved Hide resolved

sarwat12 force-pushed the NaN_fdMinMax branch from e25db7c to 07972ab Compare February 13, 2024 15:13

sarwat12 added 2 commits February 13, 2024 10:15

Enable MaxMin tests for Float/Double on LoZ, and disable them on zOS

d763955

- Enables the Float & Double MaxMin tests on Linux on Z - Disables them on z/OS, since TRIL parser cannot handle NaN values Closes: eclipse#5157 Signed-off-by: Sarwat Shaheen <sarwat.shaheen@yahoo.com>

sarwat12 force-pushed the NaN_fdMinMax branch from 07972ab to 27c1618 Compare February 13, 2024 15:15

hzongaro approved these changes Feb 14, 2024

View reviewed changes

hzongaro merged commit 0966eb3 into eclipse:master Feb 14, 2024
4 of 6 checks passed


		//Handle NaN case for doubles
		if (node->getOpCode().isDouble())

Z: Support NaN values w.r.t fmax/fmin/dmax/dmin on S390 #7196

Z: Support NaN values w.r.t fmax/fmin/dmax/dmin on S390 #7196

Conversation

sarwat12 commented Dec 6, 2023 • edited

sarwat12 commented Dec 6, 2023

sarwat12 commented Dec 6, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sarwat12 Dec 7, 2023 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sarwat12 commented Dec 13, 2023 • edited

sarwat12 commented Dec 14, 2023

r30shah left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

r30shah left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

r30shah left a comment

Choose a reason for hiding this comment

r30shah commented Jan 12, 2024

r30shah commented Jan 12, 2024 • edited

sarwat12 commented Feb 1, 2024

r30shah commented Feb 1, 2024 • edited

sarwat12 commented Feb 1, 2024

r30shah commented Feb 1, 2024

sarwat12 commented Feb 1, 2024

r30shah commented Feb 2, 2024

Choose a reason for hiding this comment

r30shah commented Feb 6, 2024

r30shah left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sarwat12 commented Feb 6, 2024

r30shah left a comment

Choose a reason for hiding this comment

r30shah commented Feb 7, 2024 • edited

r30shah commented Feb 7, 2024

r30shah left a comment

Choose a reason for hiding this comment

r30shah commented Feb 7, 2024

hzongaro left a comment

Choose a reason for hiding this comment

hzongaro left a comment

Choose a reason for hiding this comment

hzongaro commented Feb 14, 2024

sarwat12 commented Dec 6, 2023 •

edited

sarwat12 Dec 7, 2023 •

edited

sarwat12 commented Dec 13, 2023 •

edited

r30shah commented Jan 12, 2024 •

edited

r30shah commented Feb 1, 2024 •

edited

r30shah commented Feb 7, 2024 •

edited