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

[Philip Reames via llvm-dev]

I'm going to mostly stay out of the floating point specifics, but I want 
to point out a few alternative approaches which have been used elsewhere 
in the past.

We have the ability to require a intrinsic function argument to be a 
constant.  We have support for annotations printed during IR 
serialization.  Putting those together, we could use an argument 
encoding + annotation printer to field something like:

%sum = call double @llvm.experimental.constrained.fadd(double %x,
                                                        double %y, int 
0, int 1) ;; fpround.dynamic + fpexcept.strict

If we didn't want to have token types involved, we could use operand 
bundles and a custom annotator.  We'd get something like:

  %sum = call double @llvm.experimental2.constrained.fadd(double %x,
                                                         double %y) [ 
“fenv”(i32 0, i32 1)] ;; fpround.dynamic + fpexcept.strict

</end alternatives>

Personally, I'd try to avoid token types here.  Token types are 
relatively ill defined, and most of the cases we've used them have been 
a proxy for multiple variable return.  In retrospect, I wish we'd done 
multiple variable return e.g. statepoints.

Philip

On 11/14/19 11:39 AM, Kaylor, Andrew via llvm-dev 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/20191118/fd85f93d/attachment.html>