llvm dev - Feb 2020 - [RFC] Optional parameter tuples

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>

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>

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>

+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>

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
>
>