Hi, this is an RFC for optional, named parameter tuples for intrinsics. The proposed syntax is: %z = call @llvm.some.intrinsic(%a, %b) optional_tuple(%x, %y, %z) where from the perspective of the call site %x, %y and %z are simply additional parameters. Optional parameter tuples would be very useful for constrained fp intrinsics and vector predication. Some examples: ; Default fpenv fadd (isomorphic to the fadd instruction) %z = call double @llvm.fadd(%a, %b) ; Constrained fp add %x = call double @llvm.fadd(%a, %b) fpenv(metadata !fpround.tonearest, metadata !fpexcept.strict) ; Constrained fp add with vector predication (https://reviews.llvm.org/D57504) %x = call <256 x double> @llvm.fadd(%a, %b) mask(<256 x i1> %mask), evl(i32 %evl), fpenv(metadata !fpround.tozero, metadata !fpexcept.strict) 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. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200212/20eef58f/attachment.html>
Neil Henning via llvm-dev
2020-Feb-12 10:40 UTC
[llvm-dev] [RFC] Optional parameter tuples
Hey Simon, It wasn't clear from your RFC: why can't you just have these optional parameter tuples be normal function arguments to the intrinsics? Cheers, -Neil. On Wed, Feb 12, 2020 at 9:28 AM Simon Moll via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi, > > this is an RFC for optional, named parameter tuples for intrinsics. The > proposed syntax is: > > %z = call @llvm.some.intrinsic(%a, %b) optional_tuple(%x, %y, %z) > > where from the perspective of the call site %x, %y and %z are simply > additional parameters. > > Optional parameter tuples would be very useful for constrained fp > intrinsics and vector predication. Some examples: > > ; Default fpenv fadd (isomorphic to the fadd instruction) > %z = call double @llvm.fadd(%a, %b) > > ; Constrained fp add > %x = call double @llvm.fadd(%a, %b) fpenv(metadata !fpround.tonearest, metadata !fpexcept.strict) > > ; Constrained fp add with vector predication (https://reviews.llvm.org/D57504) > %x = call <256 x double> @llvm.fadd(%a, %b) mask(<256 x i1> %mask), evl(i32 %evl), fpenv(metadata !fpround.tozero, metadata !fpexcept.strict) > > 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. > > > 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 >-- Neil Henning Senior Software Engineer Compiler unity.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200212/3449124a/attachment.html>
Hi Neil, we want to make the representation more concise. One more thing i just realized is that we could use the tuple types to mask optimizations that do not expect them*. Eg standard fp optimizations could claim that they handle `llvm.fadd` unless there are any parameter tuples on it. Likewise, we can then implement a masked constrainedfp, SIMD fadd optimization pass that handles `llvm.fadd` with `fpenv` and/or `mask`. *: (this comes on the heels of a second to-be-published RFC on generalizing the pattern match logic in LLVM...) - Simon On 2/12/20 11:40 AM, Neil Henning wrote: Hey Simon, It wasn't clear from your RFC: why can't you just have these optional parameter tuples be normal function arguments to the intrinsics? Cheers, -Neil. On Wed, Feb 12, 2020 at 9:28 AM Simon Moll via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hi, this is an RFC for optional, named parameter tuples for intrinsics. The proposed syntax is: %z = call @llvm.some.intrinsic(%a, %b) optional_tuple(%x, %y, %z) where from the perspective of the call site %x, %y and %z are simply additional parameters. Optional parameter tuples would be very useful for constrained fp intrinsics and vector predication. Some examples: ; Default fpenv fadd (isomorphic to the fadd instruction) %z = call double @llvm.fadd(%a, %b) ; Constrained fp add %x = call double @llvm.fadd(%a, %b) fpenv(metadata !fpround.tonearest, metadata !fpexcept.strict) ; Constrained fp add with vector predication (https://reviews.llvm.org/D57504) %x = call <256 x double> @llvm.fadd(%a, %b) mask(<256 x i1> %mask), evl(i32 %evl), fpenv(metadata !fpround.tozero, metadata !fpexcept.strict) 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. 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<mailto:llvm-dev at lists.llvm.org> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -- [https://unity3d.com/profiles/unity3d/themes/unity/images/ui/other/unity-logo-dark-email.png] Neil Henning Senior Software Engineer Compiler unity.com<http://unity.com> Click here<https://www.mailcontrol.com/sr/au0TF3_tWkTGX2PQPOmvUnR5FqKQsdnpC6XLzZrYB6UBu_M24t1kFgX-cQcSYUrQnWsWnXyX2xbIiTKH8SslWQ==> to report this email as spam. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200212/7ce885bc/attachment-0001.html>
Johannes Doerfert via llvm-dev
2020-Feb-12 14:32 UTC
[llvm-dev] [RFC] Optional parameter tuples
On 02/12, Simon Moll via llvm-dev wrote:> Hi, > > this is an RFC for optional, named parameter tuples for intrinsics. The proposed syntax is: > > %z = call @llvm.some.intrinsic(%a, %b) optional_tuple(%x, %y, %z) > > where from the perspective of the call site %x, %y and %z are simply additional parameters. > > Optional parameter tuples would be very useful for constrained fp intrinsics and vector predication. Some examples: > > ; Default fpenv fadd (isomorphic to the fadd instruction) > %z = call double @llvm.fadd(%a, %b) > > > ; Constrained fp add > %x = call double @llvm.fadd(%a, %b) fpenv(metadata !fpround.tonearest, metadata !fpexcept.strict) > > > ; Constrained fp add with vector predication (https://reviews.llvm.org/D57504) > %x = call <256 x double> @llvm.fadd(%a, %b) mask(<256 x i1> %mask), evl(i32 %evl), fpenv(metadata !fpround.tozero, metadata !fpexcept.strict) > > 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. > > > 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.I feel this would be the right way forward, especially since your "tuple names" are basically operand bundle tags. You could express %z = call @llvm.some.intrinsic(%a, %b) optional_tuple(%x, %y, %z) as %z = call @llvm.some.intrinsic(%a, %b) ["optional_tuple"(%x, %y, %z)] or %x = call <256 x double> @llvm.fadd(%a, %b) mask(<256 x i1> %mask), evl(i32 %evl), fpenv(metadata !fpround.tozero, metadata !fpexcept.strict) as %x = call <256 x double> @llvm.fadd(%a, %b) ["mask"(<256 x i1> %mask), "evl"(i32 %evl), "fpenv"(metadata !fpround.tozero, metadata !fpexcept.strict)] Operand bundles tags can come with special semantics so we can teach parts to not "assume the worst" for such uses. I say this also because we are already heading that way for `llvm.assume`: https://reviews.llvm.org/D74209 Cheers, Johannes> 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-- Johannes Doerfert Researcher Argonne National Laboratory Lemont, IL 60439, USA jdoerfert at anl.gov -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200212/1f309d10/attachment.sig>
Reid Kleckner via llvm-dev
2020-Feb-12 15:24 UTC
[llvm-dev] [RFC] Optional parameter tuples
+1 for operand bundles, I think they are what you are looking for. On Wed, Feb 12, 2020, 6:33 AM Johannes Doerfert via llvm-dev < llvm-dev at lists.llvm.org> wrote:> On 02/12, Simon Moll via llvm-dev wrote: > > Hi, > > > > this is an RFC for optional, named parameter tuples for intrinsics. The > proposed syntax is: > > > > %z = call @llvm.some.intrinsic(%a, %b) optional_tuple(%x, %y, %z) > > > > where from the perspective of the call site %x, %y and %z are simply > additional parameters. > > > > Optional parameter tuples would be very useful for constrained fp > intrinsics and vector predication. Some examples: > > > > ; Default fpenv fadd (isomorphic to the fadd instruction) > > %z = call double @llvm.fadd(%a, %b) > > > > > > ; Constrained fp add > > %x = call double @llvm.fadd(%a, %b) fpenv(metadata !fpround.tonearest, > metadata !fpexcept.strict) > > > > > > ; Constrained fp add with vector predication ( > https://reviews.llvm.org/D57504) > > %x = call <256 x double> @llvm.fadd(%a, %b) mask(<256 x i1> %mask), > evl(i32 %evl), fpenv(metadata !fpround.tozero, metadata !fpexcept.strict) > > > > 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. > > > > > > 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. > > I feel this would be the right way forward, especially since your "tuple > names" are basically operand bundle tags. > > You could express > %z = call @llvm.some.intrinsic(%a, %b) optional_tuple(%x, %y, %z) > as > %z = call @llvm.some.intrinsic(%a, %b) ["optional_tuple"(%x, %y, %z)] > or > %x = call <256 x double> @llvm.fadd(%a, %b) mask(<256 x i1> %mask), > evl(i32 %evl), fpenv(metadata !fpround.tozero, metadata !fpexcept.strict) > as > %x = call <256 x double> @llvm.fadd(%a, %b) ["mask"(<256 x i1> %mask), > "evl"(i32 %evl), "fpenv"(metadata !fpround.tozero, metadata > !fpexcept.strict)] > > Operand bundles tags can come with special semantics so we can teach > parts to not "assume the worst" for such uses. I say this also because > we are already heading that way for `llvm.assume`: > https://reviews.llvm.org/D74209 > > Cheers, > Johannes > > > 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 > > > -- > > Johannes Doerfert > Researcher > > Argonne National Laboratory > Lemont, IL 60439, USA > > jdoerfert at anl.gov > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200212/378c1bc3/attachment.html>
Nicolai Hähnle via llvm-dev
2020-Feb-16 11:11 UTC
[llvm-dev] [RFC] Optional parameter tuples
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? 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.
Hi Nicolai, Coming back to this discussion.. 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. - 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 > >