"Kewen.Lin" <li...@linux.ibm.com> writes:
> on 2020/7/2 下午1:20, Kewen.Lin via Gcc-patches wrote:
>> on 2020/7/1 下午11:17, Richard Sandiford wrote:
>>> "Kewen.Lin" <li...@linux.ibm.com> writes:
>>>> on 2020/7/1 上午3:53, Richard Sandiford wrote:
>>>>> "Kewen.Lin" <li...@linux.ibm.com> writes:
>>>>>> + /* Decide whether to use fully-masked approach. */
>>>>>> + if (vect_verify_full_masking (loop_vinfo))
>>>>>> + LOOP_VINFO_USING_PARTIAL_VECTORS_P (loop_vinfo) = true;
>>>>>> + /* Decide whether to use length-based approach. */
>>>>>> + else if (vect_verify_loop_lens (loop_vinfo))
>>>>>> + {
>>>>>> + if (LOOP_VINFO_PEELING_FOR_GAPS (loop_vinfo)
>>>>>> + || LOOP_VINFO_PEELING_FOR_ALIGNMENT (loop_vinfo))
>>>>>> + {
>>>>>> + if (dump_enabled_p ())
>>>>>> + dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
>>>>>> + "can't vectorize this loop with
>>>>>> length-based"
>>>>>> + " partial vectors approach becuase
>>>>>> peeling"
>>>>>> + " for alignment or gaps is
>>>>>> required.\n");
>>>>>> + LOOP_VINFO_USING_PARTIAL_VECTORS_P (loop_vinfo) = false;
>>>>>> + }
>>>>>
>>>>> Why are these peeling cases necessary? Peeling for gaps should
>>>>> just mean subtracting one scalar iteration from the iteration count
>>>>> and shouldn't otherwise affect the main loop. Similarly, peeling for
>>>>> alignment can be handled in the normal way, with a scalar prologue loop.
>>>>>
>>>>
>>>> I was thinking to relax this later and to avoid to handle too many cases
>>>> in the first enablement patch. Since Power hw whose level is able to
>>>> support
>>>> vector with length, it supports unaligned load/store, need to construct
>>>> some cases for them. May I postpone it a bit? Or you prefer me to support
>>>> it here?
>>>
>>> I've no objection to postponing it if there are specific known
>>> problems that make it difficult, but I think we should at least
>>> say what they are. On the face of it, I'm not sure why it doesn't
>>> Just Work, since the way that we control the main loop should be
>>> mostly orthogonal to how we handle peeled prologue iterations
>>> and how we handle a single peeled epilogue iteration.
>>>
>>
>> OK, I will remove it to see the impact. By the way, do you think to
>> use partial vectors for prologue is something worth to trying in future?
>>
>
> I tested the updated patch with this releasing, LOOP_VINFO_PEELING_FOR_GAPS
> part looks fine, but LOOP_VINFO_PEELING_FOR_ALIGNMENT caused one case to
> fail at execution during vect-partial-vector-usage=2. So far the patch
> doesn't handle any niters_skip cases. I think if we want to support it,
> we have to add some handlings in/like what we have for masking, such as:
> mask_skip_niters, vect_prepare_for_masked_peels etc.
>
> Do you prefer me to extend the support in this patch series?
It's not so much whether it has to be supported now, but more why
it doesn't work now. What was the reason for the failure?
The peeling-with-masking thing is just an optimisation, so that we
can vectorise the peeled iterations rather than falling back to
scalar code for them. It shouldn't be needed for correctness.
Thanks,
Richard
