Hi, on 2024/4/28 16:14, Alexandre Oliva wrote: > On Apr 24, 2024, "Kewen.Lin" <li...@linux.ibm.com> wrote: > >> For !has_arch_pwr7 case, it still adopts peeling but as the comment (one >> line above) >> shows the original intention of this case is to expect not profitable for >> peeling >> so it's not expected to be handled here, can we just tweak the loop bound >> instead, >> such as: > >> -#define N 14 >> +#define N 13 >> #define OFF 4 > >> ?, it can make this loop not profitable to be vectorized for !vect_no_align >> with >> peeling (both pwr7 and pwr6) and keep consistent. > > Like this? I didn't feel I could claim authorship of this one-liner > just because I turned it into a patch and tested it, so I took the > liberty of turning your own words above into the commit message. So
Feel free to do so! > far, tested on ppc64le-linux-gnu (ppc9). Testing with vxworks targets > now. Would you like to tweak the commit message to your liking? OK, tweaked as below. > Otherwise, is this ok to install? > > Thanks, > > > adjust iteration count for ppc costmodel 76b Nit: Maybe add a prefix "testsuite: ". > > From: Kewen Lin <li...@linux.ibm.com> Thanks, you can just drop this. :) > > The original intention of this case is to expect not profitable for > peeling. Tweak the loop bound to make this loop not profitable to be > vectorized for !vect_no_align with peeling (both pwr7 and pwr6) and > keep consistent. For some hardware which doesn't support unaligned vector memory access, test case costmodel-vect-76b.c expects to see cost modeling would make the decision that it's not profitable for peeling, according to the commit history, test case comments and the way to check. For now, the existing loop bound 14 works well for Power7, but it does not for some targets on which the cost of operation vec_perm can be different from Power7, such as: Power6, it's 3 vs. 1. This difference further causes the difference (10 vs. 12) on the minimum iteration for profitability and cause the failure. To keep the original test point, this patch is to tweak the loop bound to ensure it's not profitable to be vectorized for !vect_no_align with peeling. OK for trunk (assuming the testings run well on p6/p7 too), thanks! BR, Kewen > > > for gcc/testsuite/ChangeLog > > * gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c (N): Tweak. > --- > .../gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c > b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c > index cbbfbb24658f8..e48b0ab759e75 100644 > --- a/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c > +++ b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c > @@ -6,7 +6,7 @@ > > /* On Power7 without misalign vector support, this case is to check it's not > profitable to perform vectorization by peeling to align the store. */ > -#define N 14 > +#define N 13 > #define OFF 4 > > /* Check handling of accesses for which the "initial condition" - > >
