[PATCH] D116915: [DAGCombiner][AArch64] Enhance to support for scalar CSINC
Allen zhong via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Jan 27 23:12:53 PST 2022
Allen added a comment.
Now, I can make true **the x86 debian fail** is brought in by other patch already submited in the upstream,
as it still have the same fail at the commit node **Diff 10 403452** after rolling back the change of delete the condition !RHS.hasOneUse(),
and it is successfully at the commit node **Diff 8 402198** , which has same change.
================
Comment at: llvm/lib/Target/AArch64/AArch64ISelLowering.cpp:14630
+
+ if (!CSel.hasOneUse() || !RHS.hasOneUse())
+ return SDValue();
----------------
dmgreen wrote:
> Allen wrote:
> > dmgreen wrote:
> > > I don't think it matters if the RHS has more than 1 use, it should still be OK to transform as we only use the value in another expression.
> > I had delete the condition !RHS.hasOneUse(), but recently the upstream may has some regression, it doen't finish the precommit build checking. so may I need wait a moment to figure out that issue ?
> Hmm. That sounds suspicious. What was the problem? That would usually imply an infinite loop in DAG combine, but I'm not sure how `csinc(add(x, y), x, cc)` could get back to `add(x, csel(y, 1, cc))`. Or why the uses of y matter in that case.
>
> I was about to OK the revision, but it would be good to make sure that nothing problematic is happening.
hi, dmgreen
In fact, I can't reproduce the failure base on my local building with delete the condition !RHS.hasOneUse(), so it may be not this change cause the regression, as you can see the other person's commit don't also pass building recently.
Just to be sure, do you think it is ok to roll back the change of delete the condition !RHS.hasOneUse(), and submit it firstly ? I'll resubmit the change of delete the condition !RHS.hasOneUse() after the upstream is stable with double checking.
The building log is finally came out record in https://reviews.llvm.org/harbormaster/build/215411/, and detail info can be found in [[ https://buildkite.com/llvm-project/premerge-checks/builds/76065#e9958d49-b20c-4465-ba63-7c9372fb5b4f | x86 debian fail ]]
Failed Tests (9):
libarcher :: races/critical-unrelated.c
libarcher :: races/lock-nested-unrelated.c
libarcher :: races/lock-unrelated.c
libarcher :: races/parallel-simple.c
libarcher :: races/task-dependency.c
libarcher :: races/task-taskgroup-unrelated.c
libarcher :: races/task-taskwait-nested.c
libarcher :: races/task-two.c
libarcher :: task/task_late_fulfill.c
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D116915/new/
https://reviews.llvm.org/D116915
More information about the llvm-commits
mailing list