[llvm-dev] [RFC] Optional parameter tuples

[Simon Moll via llvm-dev]

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