https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120805
--- Comment #7 from Tamar Christina <tnfchris at gcc dot gnu.org> --- (In reply to Avinash Jayakar from comment #6) > (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? No, const_vf will be 0 when vector length agnostic code is being used. i.e. a polynomial VF where it's a runtime constant but not a compile time one. And because it's a runtime constant it's the only case we can't statically set a range. In GCC AArch64 and RISC-V are 2-coeff poly targets. The previous code wasn't wrong, it just didn't support setting ranges for LOOP_VINFO_USING_PARTIAL_VECTORS_P loops. But you can set a range for a non-poly LOOP_VINFO_USING_PARTIAL_VECTORS_P loop, because as soon as your VF is known and your number of iterations are known, you can tell what the minimum and maximum number of times you iterate over your vector latch are. i.e. should your VF be 4 and your max 14, you know your range is min=1, max=4, where the final iteration processes 2 values using some kind of mask. So the question here is whether the range in GIMPLE is incorrect (as in has the wrong value). It would be good if you can isolate a testcase (of 1 function) to look at.
