[PATCH] D48193: [LoopVectorizer] Use an interleave count of 1 when using a vector library call

[Robert Lougher via Phabricator via llvm-commits]

rob.lougher added a comment.

In https://reviews.llvm.org/D48193#1133104, @hsaito wrote:

> In https://reviews.llvm.org/D48193#1133083, @rob.lougher wrote:
>
> > In https://reviews.llvm.org/D48193#1133065, @hsaito wrote:
> >
> > > I see this as a register allocator problem. It's not like we are running out of registers so that we cannot use ymm0 as a "scratch register" for SVML call. We should show the ASM code to CG experts and get the problem fixed there.
> > >
> > > Assuming that register allocator can fix simple enough issues..... I don't think it's correct to model this as a VECLIB call problem. It can happen to any function call that use too many registers that can't be shared among interleaved calls. Instead of looking at whether it's a VECLIB call or not, we should be checking how many registers are used for call/return, and how many of them cannot be shared among interleaved calls. We can then formulate this into a general register pressure issue.
> >
> >
> > The call uses one register but causes all other live values at the call location to be spilled (the other live values are caused by the interleaving).  To model this we would need to know the calling-convention of the target (which registers are preserved), and also which registers the live values will end up in.  This isn't known until after register allocation.
>
>
> Craig topper told me that LLVM currently doesn't have any special knowledge on SVML's register usage. I just checked ICC behavior. ICC uses reg-reg move. So, there appears to be a room for improvement in that area.
>  I think it's better to look into that first. Doing something blindly like this look easy but I hate to see unnecessary restrictions to be imposed. Even if we don't have a great accuracy here, we should still try to do some accounting, especially so if the calls are to something that's better behaving than the worst case.
>
> What's the value of Legal checking MayHaveVectorLibCall()? Cost model can tell whether the call is vector or scalar on its own for each VF, and that's already happened by the time selectInterleaveCount() is called.


I'm not an expert on the loop vectorizer.  From what I can see it checks to see if a vector lib call exists in 4 places:

1. Legalization
2. Planning stage
3. Cost model
4. Plan execution

Legalization just checks if we can vectorize the call (vector lib or intrinsic).  We don't know at this stage if the call will use the vector lib as it depends on the vectorization factor.

The planning stage tries various permutations of vectorization factor ranges.  Again, the planning decision is whether the call can be vectorized, which means it could be either an intrinsic or a vector lib call (within a VF range, one VF might use the intrinsic and one the vector lib, which makes it difficult to record).

The cost model is then used to calculate the expected loop cost for each VF within the VF range from planning.

At this stage the VF is then chosen (the cheapest cost).

Until this point we have been dealing with several possible VFs.  It would be possible to store within the cost model whether the vector lib call was to be used against each queried VF, but the cost model looks relatively stateless (I may be wrong but that was my impression).

So I decided to add an extra pass after the VF is chosen that looks for calls within the loop that will be vectorized with a vector library call (given the chosen VF).

Although the pass is not particularly expensive, I added MayHaveVectorLibCall() to the legalization phase.  This records if a call is seen for which a vector library call is available.  However, as stated above we can't tell if it will be used.  However, the flag is used to guard the extra pass added after the VF is chosen.  For most cases this is sufficient to avoid running the pass.


Repository:
  rL LLVM

https://reviews.llvm.org/D48193