[llvm-dev] [RFC] Optional parameter tuples (original) (raw)
Reid Kleckner via llvm-dev llvm-dev at lists.llvm.org
Wed Feb 12 07:24:39 PST 2020
- Previous message: [llvm-dev] [RFC] Optional parameter tuples
- Next message: [llvm-dev] [RFC] Optional parameter tuples
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
+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) optionaltuple(%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 environmentfpenv(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) optionaltuple(%x, %y, %z) as %z = call @llvm.some.intrinsic(%a, %b) ["optionaltuple"(%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>
- Previous message: [llvm-dev] [RFC] Optional parameter tuples
- Next message: [llvm-dev] [RFC] Optional parameter tuples
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]