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.
