[RFC][tree-vect]PR 88915: Further vectorize second loop when versioning

[Andre Vieira (lists)]

On 19/07/2019 12:35, Richard Biener wrote:
> On Fri, 19 Jul 2019, Andre Vieira (lists) wrote:
> 
>>
>>
>> On 15/07/2019 11:54, Richard Biener wrote:
>>> On Mon, 15 Jul 2019, Andre Vieira (lists) wrote:
>>>
>>>>
>>>>
>>>> On 12/07/2019 11:19, Richard Biener wrote:
>>>>> On Thu, 11 Jul 2019, Andre Vieira (lists) wrote:
>>>>
>>>>
>>>> I have code that can split the condition and alias checks in
>>>> 'vect_loop_versioning'. For this approach I am considering keeping that
>>>> bit of
>>>> code and seeing if I can patch up the checks after vectorizing the
>>>> epilogue
>>>> further. I think initially I will just go with a "hacked up" way of
>>>> passing
>>>> down the bb with the iteration check and split the false edge every time
>>>> we
>>>> vectorize it further. Will keep you posted on progress. If you have any
>>>> pointers/tips they are most welc ome!
>>>
>>> I thought to somehow force the idea that we have a prologue loop
>>> to the vectorizer so it creates the number-of-vectorized iterations
>>> check and branch around the main (highest VF) vectorized loop.
>>>
>>
>> Hmm I think I may have skimmed over this earlier. I am reading it now and am
>> not entirely sure what you mean by this. Specifically the "number of
>> vectorized iterations" or how a prologue loop plays a role in this.
> 
> When there is no prologue then the versioning condition currently
> ensures we always enter the vector loop.  Only if there is a prologue
> is there a check and branch eventually skipping right to the epilogue.
> If the versioning condition (now using a lower VF) doesn't guarantee
> this we have to add this jump-around.

Right, I haven't looked at the prologue path yet. I had a quick look and 
can't find where this branch skipping to the epilogue is constructed.  I 
will take a better look after I got my current example to work.

>>
>> I guess this sheds some light on the comment above. And it definitely implies
>> we would need to know the lowest VF when creating this condition. Which is
>> tricky.
> 
> We can simply use the smallest vector size supported by the target to
> derive it from the actual VF, no?

So I could wait to introduce this check after all epilogue vectorization 
is done, back track to the last niter check and duplicate that in the 
outer loop.

What I didn't want to do was use the smallest possible vector size for 
the target because I was under the impression that does not necessarily 
correspond to the smallest VF we may have for a loop, as the vectorizer 
may have decided not to vectorize for that vector size because of costs? 
If it I can assume this never happens, that once it starts to vectorize 
epilogues that it will keep vectorizing them for any vector size it 
knows off then yeah I can use that.


> I'm not sure I understand - why would you have any check not inside
> the outer loop?  Yes, we now eventually hoist versioning checks
> but the VF checks for the individual variants should be around
> the vectorized loop itself (so not really part of the versioning check).

Yeah I agree. I was just explaining what I had done wrong now.
> 
>> Cheers,
>> Andre
>>
>> PS: I often find myself having to patch the DOMINATOR information, sometimes
>> its easy to, but sometimes it can get pretty complicated. I wonder whether it
>> would make sense to write something that traverses a loop and corrects this,
>> if it doesn't exist already.
> 
> There's iterate-fix-dominators, but unless you create new edges/blocks
> manually rather than doing split-block/redirect-edge which should do
> dominator updating for you.

Ah I was doing everything manually after having some bad experiences 
with lv_add_condition_to_bb.  I will have a look at those thanks!

Cheers,
Andre

> 
> Richard.
> 
>>
>>>
>>> Richard.
>>>
>>
>