https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120805
--- Comment #6 from Avinash Jayakar <avinashd at linux dot ibm.com> --- (In reply to Tamar Christina from comment #5) > (In reply to Avinash Jayakar from comment #4) > > So my main doubt here is const_vf, is supposed to be 0 for the epilogue > > block right, just like log_vf was null for the epilogue. If so, this is a > > simple fix, by assigning a temporary_const_vf, and assigning the actual > > value inside the latter mentioned if block. Please do let me know, in this > > case I can create a patch. > > Is it still a problem on trunk? This was changed weeks ago in > https://gcc.gnu.org/cgit/gcc/commit/ > ?id=6c8d221b74869f2760ded2d67f95dd9d275bc1a2 and > https://gcc.gnu.org/cgit/gcc/commit/ > ?id=963d5362c598d48ee7a896e674d2a68c41179785 > > LOOP_VINFO_USING_PARTIAL_VECTORS_P is not about epilogues, but even > with epilogues we want to set range information so e.g. the loop can > be unrolled. > > The issue is just for partial vectors we need to use a ceiling rather > than a truncating division because the final iteration is partial. > > This should be reflected on trunk now. Yeah the issue still exists on the trunk. In the 2 commits you mentioned, the const_vf > 0 condition still exists. Should it not be 0 when LOOP_VINFO_USING_PARTIAL_VECTORS_P (loop_vinfo) evaluates to true? Or was the previous logic wrong? With the current code, the const_vf would always be greater than 0 right?
