[llvm-dev] [RFC] Optional parameter tuples

Simon Moll via llvm-dev llvm-dev at lists.llvm.org
Wed Feb 12 01:28:08 PST 2020


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>

More information about the llvm-dev mailing list