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

[Kaylor, Andrew via llvm-dev]

Let me clarify. These aren’t intended to be exposed to the user. The user code that leads to the generation of these intrinsics will be normal floating point operations combined with either pragmas (such as “STDC FENV_ACCESS ON”) or command line options (such as the recently introduced “-fp-model=strict”).
The reason I’ve been avoiding normal constant values is that it provides no information when you’re reading the IR. For example:

%sum = call double @llvm.experimental.constrained.fadd(double %x, double %y, i32 1, i32 2)
What does that mean? You’d need to consult an external reference to have any idea.

-Andy

From: Jameson Nash <vtjnash at gmail.com>
Sent: Thursday, November 14, 2019 12:27 PM
To: Kaylor, Andrew <andrew.kaylor at intel.com>
Cc: LLVM Developers Mailing List <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] RFC: token arguments and operand bundles

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<mailto: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<mailto: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/39ce6517/attachment-0001.html>