[llvm-dev] [RFC] Optional parameter tuples

Johannes Doerfert via llvm-dev llvm-dev at lists.llvm.org
Wed Feb 12 06:32:42 PST 2020


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>


More information about the llvm-dev mailing list