[llvm] [IR][RFC] Add @llvm.mask.beforefirst intrinsic (PR #203874)

[Paul Walker via llvm-commits]

paulwalker-arm wrote:

> > Code Modelling: I think we are long past the point where cost modelling implemented as "the sum of the cost of each instruction" is fit for purpose.
> 
> Can you elaborate on this a bit more? My understanding was that with the advancements in VPlan we're now getting representations much closer to the underlying IR which in turn makes costing per individual recipe much more accurate.
> 
> But to give a sense for the cost modeling aspect on RISC-V, because it doesn't have a get.active.lane.mask instruction a loop operating on `<vscale x 8 x i8>` will need to generate two `<vscale x 8 x i64>` vectors (one for the step vector, one to splat the result of cttz.elts). So the mask is 32 times more expensive than what it actually should be, it should only cost 1:
> 
> ```
> Cost of 32 for VF vscale x 16: EMIT vp<%uncountable.exit.mask> = active lane mask ir<0>, vp<%6>, ir<1>
> ```

Isn't this because the cost of get.actve.lane.mask is being treated in isolation? If the costing used the operands as context then it'll be much cheaper when using the two intrinsic sequence.  That's what I mean by my previous comment.  We should be calculating the cost of producing the data rather than the individual components needed to represent the computation at the IR level.
 
> From what I understand the max/min intrinsics are similar in this regard in that whilst you can represent them with an icmp + select sequence, the intrinsic is an easier canonical form. Similarly for get.active.lane.mask which can be represented with a llvm.stepvector + icmp.

I don't think get.active.lane.mask is a good example here because that was created specifically to handle the overflow characteristics that couldn't (or at least not easily) be handled using stock IR.

Like I say, I'm not against the new intrinsic, but it would be useful to have some guidelines to use when deciding if there's sufficient value.


https://github.com/llvm/llvm-project/pull/203874