[PATCH] vect: Fix epilogue loop handling of partial vectors

[Kewen.Lin]

Hi Richard,

on 2020/9/22 下午10:34, Richard Sandiford wrote:
> Richard Sandiford <richard.sandiford@arm.com> writes:
>> I'll try to have a patch ready tomorrow morning European time.
> 
> Well, I totally failed to hit that deadline.  When testing on Power,
> I saw a couple of extra failures, but I now think they're improvements

Thanks for the testing!

> rather than regressions.  See the point about single-iteration
> epilogues below.
> 
> ---
> 
> This patch fixes the fallout that Kewen reported on Power after
> the recent change to avoid unnecessary use of partial vectors.
> As Kewen said, the problem is that vect_analyze_loop_2 doesn't
> know how many epilogue iterations there will be, and so it
> cannot make a final decision about whether the number of
> iterations forces an epilogue loop to use partial vectors.
> 
> This is similar to the current situation for peeling: we don't know
> during initial analysis whether an epilogue loop will itself require
> peeling.  Instead we decide that during vect_do_peeling, where the
> final number of epilogue loop iterations is known.
> 
> The patch takes a similar approach for the decision about whether
> to use partial vectors.  As the comments in the patch say, the
> idea is that vect_analyze_loop_2 should make peeling and partial-
> vector decisions based on the assumption that the loop_vinfo will
> be used as the main loop, while vect_do_peeling should make them
> in the knowledge that the loop_vinfo will be used as an epilogue loop.
> 
> This allows the same analysis to be used for both cases, which we
> rely on for implementing VECT_COMPARE_COSTS; see the big comment
> in vect_analyze_loop for details.
> 
> I hope the patch makes the (mostly preexisting) structure a bit
> more obvious.  It isn't what anyone would design from scratch,
> but that's the nature of working with a mature vector framework.
> 
> Arranging things this way means that vect_verify_full_masking
> and vect_verify_loop_lens now become part of the “can” rather
> than “will” test for partial vectors.
> 
> Also, while splitting out the logic that handles epilogues with
> constant iterations, I added a check to make sure that we don't
> try to use partial vectors to vectorise a single-scalar loop.
> This required some changes to the Power tests.

Thanks for the great rework!  Using partial vector should be more
costly than just being with one single scalar iteration, I think
this is an improvement.  But I'm not sure whether someone would
argue that in the context of no-vect-cost-model, it's expected to
go with vectorized code, cost-modeling check can punt this when
it takes effects.  Personally I'm fine on this anyway.

BR,
Kewen