https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120805
--- Comment #20 from Avinash Jayakar <avinashd at linux dot ibm.com> --- (In reply to Tamar Christina from comment #19) > (In reply to Avinash Jayakar from comment #18) > > (In reply to Tamar Christina from comment #17) > > > (In reply to Avinash Jayakar from comment #16) > > > > Created attachment 61956 [details] > > > > I have just changed the order within the conditional where the const_vf > > > > gets > > > > assigned, to have it behave in similar way as before (use of log_vf) > > > > > > That to me is just a plaster rather than a fix. You've flipped the > > > initialization of logvf rather than just adding the explicit requirement > > > that this code can't support epilogues. > > > > ok, but adding a statement that it does not support epilogue is also a > > plaster right? because there can be other cases where > > LOOP_VINFO_USING_PARTIAL_VECTORS_P (loop_vinfo) > > is true, and epilogue is just one of them. So if there is a scenario like > > that, then we would have to not support those cases explicitly. > > If we are definitely sure that LOOP_VINFO_USING_PARTIAL_VECTORS_P > > (loop_vinfo) would be true for epilogues only when vf > 0, then the fix you > > suggested will work. I am not sure if that is the case. If the patch is not > > convincing, you can take this issue. > > But partial loops are *not* the problem. LOOP_VINFO_USING_PARTIAL_VECTORS_P > just means your loop is masked, i.e. you may have a partial iteration. If > LOOP_VINFO_USING_PARTIAL_VECTORS_P is on the main loop the range *is* > correct because niters_vector is then an actual vector iteration count. You > can have a partial main loop and zero epilogues. This is usually just a cost > modeling decision. > > Epilogues are the problem, and before the check on > !LOOP_VINFO_USING_PARTIAL_VECTORS_P just happen to block epilogues on > PowerPC because PowerPC is a non-poly target which generated an unpredicated > main loop and a predicated non-VLA epilogue. > > It's when it's an epilogue that niters_vector has not been adjusted to > vector iterations. i.e. it's scalar. that's why you cannot set a vector > iteration bounds on the scalar bnd value as I explained here > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120805#c13. > > When it's an epilogue, the bounds value is not used in the latch of the loop, > because there is no latch, epilogues will have their loop control removed as > they can by definition only do VF values (i.e, one iteration). Alright, you can create a patch for this bug in that case then, since you had proposed the patch. Thanks.
