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

[Simon Moll via llvm-dev]

Hi,

@Andy, thanks for the RFC and being open to discussion regarding the constrained fp encoding.

On 11/15/19 5:00 AM, Jameson Nash via llvm-dev wrote:
I understand that, but I think you missed my point. Not all front-ends are clang, and non-C frontends are also interested in this work. And even C might want to eventually want to be able to use these more generally. For example, the current C standard (afaik) doesn't define what must happen if this pragma tried to use a non-literal constant, such as a template attribute as the arguments. But it's not obvious to me why LLVM should inherit that limitation. Currently it seems to be implemented in a way that requires special handling in any front-end, influenced strong by the special handling it's now getting in C. For other languages, it's doable to expose this to users regardless, but if you're already considering changing it, my vote would be to use a normal representation with first-class values.

Constrained FP rounding mode and exception args do **not** specify the rounding mode or exception behavior - the parameters simply explain to LLVM how the operations behave so they can be analyzed/optimized under that assumption. The actual fp environment is configured by other means. As such there is little value in allowing variable exception/rounding mode params for the contrained fp intrinsics - LLVM passes wouldn't understand them (in all but trivial cases) and would have to assume the worst case (dynamic/strict) anyway.

Besides, there is no going back from dynamic fpexcept/fpround to constants but we can always opt in when the need arises.

I guess the exact meaning of the fpround and fpexcept params could be explained better in the LangRef.

However, I  really appreciate the specifics on the concern you brought up, because that's a good point. If it's just about better IR printing, perhaps we can just address that directly?

Most simply, perhaps these calls could customize the printing to append a comment? Some places already do that, for example to show Function Attributes.

Similarly, but more major, LLVM could perhaps define a new "named constant" syntax for the parser format (either with special tokens like your current PR and/or that get defined elsewhere like existing global constants). Certain instructions (such as these) could then use the option to customize the printing of their arguments to use the named constant (after parsing, they'd just be a normal Constant-only printing would optionally use them to show the information better to the reader).

To me it seems constant tokens do the job just fine without the need for a custom code path.
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")


Does that seem like a valid use of tokens and operand bundles? Does it seem better than the current approach?

I really like the operand bundle approach because it makes the round/except parameters optional. Basically, a llvm.experimental.constrained.fadd(%x, %y) without the operand bundle (and without the 'strictfp' attribute - hypothetically) would lower directly to an 'fadd'. At least that is the way i am planning to use it for vector-predicated fp ops.

Cheers,

Simon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191115/2863f8e5/attachment.html>