[PATCH] D69891: [VP,Integer,#1] Vector-predicated integer intrinsics

[Andy Kaylor via Phabricator via llvm-commits]

andrew.w.kaylor added a comment.

In D69891#1854113 <https://reviews.llvm.org/D69891#1854113>, @SjoerdMeijer wrote:

> > I'm not entirely clear where this value comes from, but it seems like whatever generated it must know that we're generating SVE code, right?
>
> This is not architecture specific, and thus this is not assuming SVE. In the case of SVE, the vector length is unknown at compile time (it is a multiple of something), and constant at run-time. In the RISC-V vector extension, I believe it can be changed at any point. Thus, the way to obtain this value is by reading/writing a status register, or something similar, but relying on querying the architecture features. And whether it is constant at runtime, or can be changed at any point, this API seems to cover the different cases.


Alright, I was reaching for a more general concept that I obviously don't know the term for. What I meant to say was just that whatever generated the argument must know something specific about the target architecture.

In D69891#1854301 <https://reviews.llvm.org/D69891#1854301>, @simoll wrote:

> Operand bundles are not the same as optional parameters. Operand bundles pessimistically imply side-effects where as a plain `i32` argument is innocuous to optimizations:
>
> > https://llvm.org/docs/LangRef.html#operand-bundles
> > 
> > - Calls and invokes with operand bundles have unknown read / write effect on the heap on entry and exit (even if the call target is readnone or readonly), unless they’re overridden with callsite specific attributes.
>
> That is reasonable for constrained fp intrinsics, which always have such a dependence. Many VP intrinsics however do not have any side effects or only inspect/modify memory through their pointer arguments, etc.


We could add a callsite attribute when the intrinsic is created. We have that information about the intrinsic, right?

I'll admit that there may be no practical difference between what you've proposed and what I have in mind (in the abstract sense that assumes it's even possible to implement this in the way that I'm imagining). Mostly, I'm trying to explore what I perceive to be a bad smell in the IR. Having a parameter that is irrelevant for some targets just doesn't seem right. Introducing these intrinsics with "experimental" in the name would make me feel a bit better about that, even though again it has no practical effect.

In D69891#1854257 <https://reviews.llvm.org/D69891#1854257>, @rkruppe wrote:

> The real question is, do targets without native support for EVL have anything to gain from making the argument optional?


I'm not sure I agree that is the real question. What is gained by not having the floating point constraint arguments always present even when they aren't needed? We have values that describe the default mode, so we could use those when we want the default mode. I think we all agree that they shouldn't be there when we don't need them, yet I would argue that those arguments are more relevant when "not needed" than the evl argument is.

I'm imagining walking someone through the IR, explaining what each instruction means. I'd be a bit embarrassed when I get to a vp intrinsic and say, "Ignore the last argument. We don't use it for this target."

But like I said above, this is much more a vague indication to me that we haven't got this right yet than a concrete problem.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69891/new/

https://reviews.llvm.org/D69891