[llvm-dev] RFC: token arguments and operand bundles

[Jameson Nash via llvm-dev]

>From a front-end perspective, I think it'd be preferable if these either
got encoded in the function name or were normal enum value arguments. It's
a bit awkward to expose things to the user that must be constant or of a
special type or in a special metadata slot, since we now need more special
support for it. If the optimization passes couldn't identify a constant
value for one of the arguments, these seem like they can fallback to
assuming the most conservative semantics (of round.dynamic and
fpexcept.strict--e.g. don't optimize) without loss of precision or
generality.

-Jameson

On Thu, Nov 14, 2019 at 2:40 PM Kaylor, Andrew via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hello everyone,
>
>
>
> I’ve just uploaded a patch (https://reviews.llvm.org/D70261) to introduce
> a could of new token types to be used with constrained floating point
> intrinsics and, optionally, vector predicated intrinsics. These intrinsics
> may not be of interest to many of you, but I have a more general question.
>
>
>
> I would like some general feedback on the way I am proposing to use token
> arguments and operand bundles. I have an incomplete understanding of how
> these are intended to be used, and I want to make sure what I have in mind
> is consistent with the philosophy behind them.
>
>
>
> Currently, the constrained floating point intrinsics require string
> metadata arguments to describe the rounding mode and exception semantics.
> These “arguments” are really providing information to the optimizer about
> what it can and cannot assume when acting on these intrinsics. The rounding
> mode argument potentially overrides the default optimizer assumption that
> the “to nearest” rounding mode is in use, and the exception behavior
> argument overrides the default optimizer assumption that floating point
> operations have no side effects. I’ve never liked the use of strings here,
> and the fact that these arguments are not actually inputs to the operation
> represented by the intrinsic seems vaguely wrong.
>
>
>
> A typical call to a current intrinsic looks like this:
>
>
>
> *%sum = call double @llvm*.experimental.constrained.fadd(double %x,
>
>                                                        double %y,
>
>                                                        Metadata
> “fpround.dynamic”,
>
>                                                        Metadata
> “fpexcept.strict”)
>
>
>
> The idea I am pursuing in my patch is to replace these metadata arguments
> with optional operand bundles, “fpround” and “fpexcept”. If the operand
> bundles are present, they would mean what the arguments currently mean. If
> not, the default assumption is allowed. A typical call to a constrained
> intrinsic would look like this:
>
>
>
> *%sum = call double @llvm*.experimental2.constrained.fadd(double %x,
>
>                                                         double %y) [
> “fpround”(token rmDynamic),
>
>
>                     “fpexcept”(token ebStrict) ]
>
>
>
> Does that seem like a valid use of tokens and operand bundles? Does it
> seem better than the current approach?
>
>
>
> Thanks,
>
> Andy
> _______________________________________________
> 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/20191114/0074ca8b/attachment.html>