[llvm-dev] [RFC] Optional parameter tuples

Nicolai Hähnle via llvm-dev llvm-dev at lists.llvm.org
Tue Mar 10 09:49:23 PDT 2020


On Tue, Mar 10, 2020 at 1:41 PM Simon Moll <Simon.Moll at emea.nec.com> wrote:
> On 2/16/20 12:11 PM, Nicolai Hähnle wrote:
> > Hi Simon,
> >
> > On Wed, Feb 12, 2020 at 10:28 AM Simon Moll via llvm-dev
> > <llvm-dev at lists.llvm.org> wrote:
> >> For constrained fp and VP, we only require a very restricted form of this. That is:
> >>
> >> - Tuples are only allowed on intrinsic function calls.
> >>
> >> - There is a builtin list of allowed tuple types (eg tablegen file).
> >>
> >> - Tuple types are opt in: Intrinsics define a list of permissible tuple types.
> >>
> >> - Tuple parameters have default values when a tuple is absent at a call site. Eg, for `fpenv` the default fp environment `fpenv(fpround.tonearest, fpexcept.ignore)` is implied in the first example above.
> > This seems a pretty interesting idea. It's something we could consider
> > long-term for the AMDGPU image.sample intrinsics. Image sample
> > intrinsics have fairly complex "address" parameters, consisting of a
> > "body" (s,t,r coordinates, depending on the image dimensionality) and
> > optional extra parameters such as "lod bias", "z compare reference
> > variable", "texel offsets". Those optional extra parameters could be
> > an application of optional parameter tuples.
> >
> > Have you given any thought to how this would be presented in
> > MachineIR, especially through the GlobalISel path?
>
> To get things off the ground quickly, the optional parameters on
> IR-level could be lowered to regular, explicit parameters (or SDNode
> properties). So, omitting a tuple in IR would mean passing a default
> parameter in ISel. This default parameter on isel level could be a
> special \bottom token that implies that this parameter is not set.

Sure, that seems reasonable.

Cheers,
Nicolai


>
> - Simon
>
> >
> > Cheers,
> > Nicolai
> >
> >
> >
> >>
> >> Btw, different to operand bundles, optional parameter tuples are much more restricted and do not imply side effects of any kind. We might want to re-use the OpBundle logic for this though.
> >>
> >> There are probably more use cases for this and i'd like to hear about them.
> >>
> >> Looking forward to your feedback
> >>
> >> - Simon
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
> >
>


-- 
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.


More information about the llvm-dev mailing list