[mlir][arith] Initial support for fastmath flag attributes in the Arithmetic dialect (v2)

[jfurtek]

Summary

This diff adds initial (partial) support for "fastmath" attributes for floating
point operations in the arithmetic dialect. The "fastmath" attributes are
implemented using a default-valued bit enum. The defined flags currently mirror
the fastmath flags in the LLVM dialect (and in LLVM itself). Extending the
set of flags (if necessary) is left as a future task.

In this diff:

• Definition of FastMathAttr as a custom attribute in the Arithmetic dialect that inherits from the EnumAttr class.
• Definition of ArithFastMathInterface, which is an interface that is implemented by operations that have an arith::fastmath attribute.
• Declaration of a default-valued fastmath attribute for unary and (some) binary floating point operations in the Arithmetic dialect.
• Conversion code to lower arithmetic fastmath flags to LLVM fastmath flags

NOT in this diff (but planned or currently in progress):

• Documentation of flag meanings
• Addition of FastMathAttr attributes to other dialects that might lower to the Arithmetic dialect (e.g. Math and Complex)
• Folding/rewrite implementations that are enabled by fastmath flags
• Specification of fastmath values from Python bindings (pending other in- progress diffs)

[jfurtek]

• Fix clang formatting

[jfurtek]

Adding @mehdi_amini since he had some feedback on a previous iteration of this functionality.

[jfurtek]

• rebase

[mehdi_amini]

mlir/lib/Conversion/LLVMCommon/Pattern.cpp

43

I'd rather make it return just the llvmAttr to avoid rebuilding the StringAttr for the name: either the call-site already have it or they don't and they may not even care about it.
(it also seems more coherent as an API to not return a named attribute when the input is just the attribute value here)

mlir/lib/Dialect/Arithmetic/IR/ArithmeticOps.cpp

49

Can we instead print the fast math separately from the other attribute in a more friendly form?

Instead of:

%0 = arith.addf %arg0, %arg1 {fastmath = #arith.fastmath<fast>} : f32

I'd rather read:

%0 = arith.addf %arg0, %arg1 fastmath<fast> : f32
%1 = arith.addf %arg0, %arg1 fastmath<fast> { other_attribute = ... } : f32

Calling arithFMAttr.print() should print it this way directly.

[jfurtek]

• Change fastmath print/parse format based on review comments.
• Refactor attribute lowering.

[mehdi_amini]

Thanks!

[jfurtek]

Subsequent code for python bindings of default-valued attributes has broken the code in this diff - needs to be fixed.

[vzakhari]

Thank you for working on this @jfurtek!

I guess this may be changed later: in light of extending this to more dialects, does it make sense to make ArithFastMathInterface not-arith specific from the beginning and replace LLVM dialect's FastmathFlagsInterface with the same base interface?

[jfurtek]

Thank you for working on this

I am hoping that others will find it useful! I have more functionality working locally - I am waiting on some other diffs (regarding Python handling of default-valued attributes) to land before having those reviewed.

I guess this may be changed later: in light of extending this to more dialects, does it make sense to make ArithFastMathInterface not-arith specific from the beginning and replace LLVM dialect's FastmathFlagsInterface with the same base interface?

I tried to minimize changes to the LLVM dialect - at least initially - just to reduce the scope of the diff. It may be possible to have them share the same interface and bit enumeration.

However, I was thinking that at some point MLIR::Arithmetic might want to have flags that are not present in LLVM - for whatever reason. (Hypothetically speaking, such a flag could be derived from the fact that Arithmetic operations can be applied to tensors, or it could be used and removed before lowering to LLVM, or it could be used when lowering to something that is not LLVM.) I don't have a strong opinion, but I would be inclined to keep the Arithmetic and LLVM flags separate. (The code to convert from Arithmetic to LLVM flags is minimal.)

[vzakhari]

In D126305#3676838, @jfurtek wrote:

I guess this may be changed later: in light of extending this to more dialects, does it make sense to make ArithFastMathInterface not-arith specific from the beginning and replace LLVM dialect's FastmathFlagsInterface with the same base interface?

I tried to minimize changes to the LLVM dialect - at least initially - just to reduce the scope of the diff. It may be possible to have them share the same interface and bit enumeration.

However, I was thinking that at some point MLIR::Arithmetic might want to have flags that are not present in LLVM - for whatever reason. (Hypothetically speaking, such a flag could be derived from the fact that Arithmetic operations can be applied to tensors, or it could be used and removed before lowering to LLVM, or it could be used when lowering to something that is not LLVM.) I don't have a strong opinion, but I would be inclined to keep the Arithmetic and LLVM flags separate. (The code to convert from Arithmetic to LLVM flags is minimal.)

Thank you for the explanation! It makes sense to keep the two interfaces separate at this point.

[vzakhari]

Mostly looks good to me.

mlir/include/mlir/Conversion/LLVMCommon/Pattern.h

44

The non-method name should probably sound like convertedAttrs.

mlir/lib/Conversion/LLVMCommon/Pattern.cpp

20

auto should probably be replaces with concrete type.

38

Please replace auto.

[kiranchandramohan]

Thanks for working on this @jfurtek. Will you be able to land this in the next two weeks? Are there plans for supporting these attributes in the math dialect and func dialect?

mlir/include/mlir/Dialect/Arithmetic/IR/ArithmeticOpsInterfaces.td

41

Nit: newline

[jfurtek]

In D126305#3820641, @kiranchandramohan wrote:

Thanks for working on this @jfurtek. Will you be able to land this in the next two weeks?

I will pick this back up and try to have an updated diff ready for re-review today or tomorrow...

Are there plans for supporting these attributes in the math dialect and func dialect?

I expect to spread fastmath support to math (and some other dialects). I think once this diff lands, it would become easier for anyone else to do it as well.

I'm less clear on how this would work with the func dialect though (since you mentioned it specifically). I seem to recall some discussion in LLVM about whether a function-level attribute makes sense:

https://reviews.llvm.org/D14707

For example, how do you reconcile a function-level fastmath attribute that conflicts with those that might exist on individual ops when inlining? Maybe @mehdi_amini would have some thoughts on this.

[mehdi_amini]

https://reviews.llvm.org/D14707
For example, how do you reconcile a function-level fastmath attribute that conflicts with those that might exist on individual ops when inlining? Maybe @mehdi_amini would have some thoughts on this.

This may be tricky to handle with generality, I'd have to think about this and look into scenario.
The first question is what is the semantics of a call with a fast math attribute when the called function does not have it? Maybe conceptually the attribute could be propagate to the entire function? (assuming it is the only call site for the function, or all call sites have the attribute)

[vzakhari]

In D126305#3821610, @mehdi_amini wrote:

https://reviews.llvm.org/D14707
For example, how do you reconcile a function-level fastmath attribute that conflicts with those that might exist on individual ops when inlining? Maybe @mehdi_amini would have some thoughts on this.

This may be tricky to handle with generality, I'd have to think about this and look into scenario.
The first question is what is the semantics of a call with a fast math attribute when the called function does not have it? Maybe conceptually the attribute could be propagate to the entire function? (assuming it is the only call site for the function, or all call sites have the attribute)

Just my two cents. In an example of separate modules compilation and user functions, i.e. function definition is in one translation module and the call site is in another, I think we should give users possibility to use different math optimization settings for the modules. So I think propagating mismatching fast math flags from the call site to the function or even its inlined copy (e.g. with MLIR inter-module inlining) would be incorrect. I believe LLVM inlining actually works this way and it seems correct to me.

Example:
main.c:

#include <math.h>
#include <stdio.h>
extern float foo(float x);

int main(int argc, char *argv[]) {
  printf("%e %e\n", foo(argc), cosf(argc));
  return 0;
}

foo.c:

#include <math.h>
float foo(float x) {
  return sinf(x);
}

clang -O3 -ffast-math main.c -flto -c
clang -O3 foo.c -flto -c
clang -O3 main.o foo.o -flto -lm -Wl,-plugin-opt=-print-after-all 2>log

After inlining we will have:

*** IR Dump After InlinerPass on (main) ***
; Function Attrs: nofree nounwind uwtable
define dso_local i32 @main(i32 noundef %0, ptr nocapture noundef readnone %1) local_unnamed_addr #0 {
...
  %4 = tail call float @sinf(float noundef %3) #4
...
  %6 = tail call fast float @llvm.cos.f32(float %3)
...
}

As you may see the inliner preserved the function definition's behavior instead of propagating the call-site attributes to the inlined copy.

[mehdi_amini]

What is the intended meaning of the fast math attribute on the call to foo in main?

[tschuett]

The LLVM Langref might help you with these questions.

[vzakhari]

In D126305#3824892, @mehdi_amini wrote:

What is the intended meaning of the fast math attribute on the call to foo in main?

This is a good question :)
Fast math flags can be attached to LLVM call instructions, so I guess clang does this unconditionally based on the driver option. I am not sure if it is intentional, but it seems that nnan, ninf and nsz can potentially be applied even to user function call. Whether these flags have any effect on user function calls - I do not know.

[mehdi_amini]

In D126305#3824904, @tschuett wrote:

The LLVM Langref might help you with these questions.

Can you elaborate maybe? Did you found something more than I did?

The optional fast-math flags marker indicates that the call has one or more fast-math flags, which are optimization hints to enable otherwise unsafe floating-point optimizations. Fast-math flags are only valid for calls that return a floating-point scalar or vector type, or an array (nested to any depth) of floating-point scalar or vector types.

This isn't helpful here...

[jfurtek]

Will you be able to land this in the next two weeks?

Apologies for the delay - I am still finishing this up. The code has been rebased, and I am just clearing up new test failures.

Are there plans for supporting these attributes in the ... func dialect?

We can try to be compatible with LLVM, but I was thinking that we might not need the fastmath attribute at the function and module levels. (There is some brief discussion from 2016 about LLVM moving away from function-level attributes for fastmath in this video.) I suspect that for most practical module and function scenarios (setting flags globally, propagating attributes through inlining, ...) MLIR passes and the Transform dialect could accomplish the same thing.

[vzakhari]

In D126305#3833476, @jfurtek wrote:

Will you be able to land this in the next two weeks?

Apologies for the delay - I am still finishing this up. The code has been rebased, and I am just clearing up new test failures.

Are there plans for supporting these attributes in the ... func dialect?

We can try to be compatible with LLVM, but I was thinking that we might not need the fastmath attribute at the function and module levels. (There is some brief discussion from 2016 about LLVM moving away from function-level attributes for fastmath in this video.) I suspect that for most practical module and function scenarios (setting flags globally, propagating attributes through inlining, ...) MLIR passes and the Transform dialect could accomplish the same thing.

Hi @jfurtek, so Hal was talking about making math "settings" more exact by attaching the flags to instructions rather than keeping them on the function/module level. I believe this implies that the call instructions may have math flags attached, and I think this is what we probably want to have in MLIR as well (e.g. for func.call operations produced by ToLibm convertors). There indeed seem to be no reason to have math flags attached to func.func operations.

[kiranchandramohan]

In D126305#3847598, @vzakhari wrote:

In D126305#3833476, @jfurtek wrote:

Will you be able to land this in the next two weeks?

Apologies for the delay - I am still finishing this up. The code has been rebased, and I am just clearing up new test failures.

Are there plans for supporting these attributes in the ... func dialect?

We can try to be compatible with LLVM, but I was thinking that we might not need the fastmath attribute at the function and module levels. (There is some brief discussion from 2016 about LLVM moving away from function-level attributes for fastmath in this video.) I suspect that for most practical module and function scenarios (setting flags globally, propagating attributes through inlining, ...) MLIR passes and the Transform dialect could accomplish the same thing.

Hi @jfurtek, so Hal was talking about making math "settings" more exact by attaching the flags to instructions rather than keeping them on the function/module level. I believe this implies that the call instructions may have math flags attached, and I think this is what we probably want to have in MLIR as well (e.g. for func.call operations produced by ToLibm convertors). There indeed seem to be no reason to have math flags attached to func.func operations.

OK. I was just asking because clang-generated code seemed to have these fast function attributes. If clang/llvm's plan is to move away then let us not support it for now in the func dialect. We can revisit if necessary later.

We need the fast attribute support in Flang. We have started working on the driver to support this. I believe @vzakhari plans to extend this to the math dialect. We would like to generate some numbers for Flang with the Ofast flag. It will be great to see this submitted soon.

[jfurtek]

• Fix clang formatting
• Change fastmath print/parse format based on review comments. Refactor attribute lowering.
• Update MLIRArithmeticDialect CMake reference
• Add fastmath attribute binding to arith canonicalizations
• Fixes for compile failures after rebase
• Modify LLVM fastmath interface to be attribute-based instead of value-based.

[jfurtek]

• Update LLVM lowering logic to drop fastmath attributes for targets that do not support the interface.

[vzakhari]

LGTM. Thank you!

[tpopp]

mlir/lib/Conversion/LLVMCommon/CMakeLists.txt

18

It seems weird to add a dependency on the Arith Dialect here.

[jfurtek]

It seems weird to add a dependency on the Arith Dialect here.

This is a good point - let me see if I can avoid that...

[tpopp]

In D126305#3871463, @jfurtek wrote:

It seems weird to add a dependency on the Arith Dialect here.

This is a good point - let me see if I can avoid that...

I might be wrong, and I was just leaving a passing comment as I saw it, so please don't wait on my approval, whenever you and your reviewers are happy with the change :)

[jfurtek]

• Fix clang formatting
• Change fastmath print/parse format based on review comments. Refactor attribute lowering.
• Update MLIRArithmeticDialect CMake reference
• Add fastmath attribute binding to arith canonicalizations
• Fixes for compile failures after rebase
• Modify LLVM fastmath interface to be attribute-based instead of value-based.
• Update LLVM lowering logic to drop fastmath attributes for targets that do not support the interface.
• Remove arith dependency from LLVMCommon. Move attribute conversion to the specific conversion module (in this case ArithToLLVM).

[jfurtek]

• Fix clang formatting
• Change fastmath print/parse format based on review comments. Refactor attribute lowering.
• Update MLIRArithmeticDialect CMake reference
• Add fastmath attribute binding to arith canonicalizations
• Fixes for compile failures after rebase
• Modify LLVM fastmath interface to be attribute-based instead of value-based.
• Update LLVM lowering logic to drop fastmath attributes for targets that do not support the interface.
• Remove arith dependency from LLVMCommon. Move attribute conversion to the specific conversion module (in this case ArithToLLVM).
• clang-formatting fix
• clang formatting fix

[jfurtek]

I might be wrong, and I was just leaving a passing comment as I saw it

I think the comment was spot on - thanks for the suggestion. I fixed it in a subsequent commit.

[vzakhari]

mlir/include/mlir/Conversion/LLVMCommon/VectorPattern.h

99 ↗

(On Diff #469812)

Can we avoid specifying SourceOp by templatizing the constructors of AttrConvertPassThrough, AttrConvertFastMath and AttrDropFastMath by their argument type? It seems to be redundant to specify SourceOp as long as it is deducible from the constructor argument.

[vzakhari]

mlir/include/mlir/Conversion/LLVMCommon/VectorPattern.h

99 ↗

(On Diff #469812)

Here is an example of where this will help to avoid some redundancy: https://reviews.llvm.org/D136312#change-SuMljwYyXLk3 (ConvertFastMathHelper wrapper currently has 6 uses in math::ExpM1Op, math::Log1pOp and math::RsqrtOp converters).

[jfurtek]

mlir/include/mlir/Conversion/LLVMCommon/VectorPattern.h

99 ↗

(On Diff #469812)

I disagree that templatizing the constructor is preferable. For the trivial case here that works, but if I look ahead to (for example) an attribute converter that chains together conversions for more than one attribute, I think that being able to specialize on the converter class will be more flexible and clean than specializing or overloading the constructor.

Your linked example already specifies the target type in the class template and the matchAndRewrite() function anyway, so it doesn't seem to be to be a huge amount of additional redundancy.

This is just my opinion - feel free to make that change as part of your child diff.

[vzakhari]

mlir/include/mlir/Conversion/LLVMCommon/VectorPattern.h

99 ↗

(On Diff #469812)

I was referring to places like this:

ConvertFastMathHelper<LLVM::ExpOp> expAttrs(op);
ConvertFastMathHelper<LLVM::FSubOp> subAttrs(op);

If I were to use AttrConvert interface directly it would look like this:

ConvertFastMath<math::ExpM1Op, LLVM::ExpOp> expAttrs(op);
ConvertFastMath<math::ExpM1Op, LLVM::FSubOp> subAttrs(op);

I agree, this is not a huge amount of redundancy, so I am okay with it as it is.

[jfurtek]

• Fix clang formatting
• Change fastmath print/parse format based on review comments. Refactor attribute lowering.
• Update MLIRArithmeticDialect CMake reference
• Add fastmath attribute binding to arith canonicalizations
• Fixes for compile failures after rebase
• Modify LLVM fastmath interface to be attribute-based instead of value-based.
• Update LLVM lowering logic to drop fastmath attributes for targets that do not support the interface.
• Remove arith dependency from LLVMCommon. Move attribute conversion to the specific conversion module (in this case ArithToLLVM).
• clang-format fix
• clang formatting fix
• More clang-formatting

[rkayaith]

mlir/include/mlir/Dialect/Arith/IR/ArithOps.td

86 ↗

(On Diff #470892)

you should be able to avoid the custom formatting now:

[mehdi_amini]

You have got a notification about this breakage https://lab.llvm.org/buildbot/#/builders/61/builds/34355 ?

I tried to fix in https://github.com/llvm/llvm-project/commit/8f4320cf1d5f115fa98652ce8765157557aeaaea ; hopefully it's enough.

[vzakhari]

In D126305#3886949, @mehdi_amini wrote:

You have got a notification about this breakage https://lab.llvm.org/buildbot/#/builders/61/builds/34355 ?

I tried to fix in https://github.com/llvm/llvm-project/commit/8f4320cf1d5f115fa98652ce8765157557aeaaea ; hopefully it's enough.

Thank you, Mehdi! I wish the committers were also notified about the breakages.

[jfurtek]

mlir/include/mlir/Dialect/Arith/IR/ArithOps.td

86 ↗

(On Diff #470892)

The documentation for Optional Groups says that "only optional attributes can be marked as the anchor." In this case, the attribute is not optional, it is default-valued. Will this still work?

[rkayaith]

mlir/include/mlir/Dialect/Arith/IR/ArithOps.td

86 ↗

(On Diff #470892)

It should work since D134993. I need to update that line in the docs though, thanks for pointing it out.

mlir/include/mlir/Conversion/LLVMCommon/Pattern.h

 namespace LLVM {
 namespace detail {
 /// Replaces the given operation "op" with a new operation of type "targetOp"
 /// and given operands.
 LogicalResult oneToOneRewrite(Operation *op, StringRef targetOp,
                               ValueRange operands,
                               LLVMTypeConverter &typeConverter,
                               ConversionPatternRewriter &rewriter);
+
+/// Class to manage named attributes for lowering ops to LLVM. For ops that
+/// require attribute modification, an internal vector of named attributes
+/// will be populated with attributes for the destination LLVMIR operation.
+/// For those ops that do not require modification, a reference to the original
+/// source attributes will be returned by the getAttrs() function. (This class
+/// is currently only suitable for "universal" rules, as conversion decisions
+/// are made in the class constructor.)
+class ConvertToLLVMAttributes {
+public:
+  ConvertToLLVMAttributes(Operation *op);
+  ArrayRef<NamedAttribute> getAttrs() const {
+    return convertAttrs ? convertAttrs.getValue() : srcAttrs;
+  }
+
+private:
+  using AttrVector = SmallVector<NamedAttribute, 4>;
+  ArrayRef<NamedAttribute> srcAttrs;
+  Optional<AttrVector> convertAttrs;
+};
 } // namespace detail
 } // namespace LLVM
 
 /// Base class for operation conversions targeting the LLVM IR dialect. It
 /// provides the conversion patterns with access to the LLVMTypeConverter and
 /// the LowerToLLVMOptions. The class captures the LLVMTypeConverter and the
 /// LowerToLLVMOptions by reference meaning the references have to remain alive
 /// during the entire pattern lifetime.

mlir/include/mlir/Dialect/Arithmetic/IR/Arithmetic.h

 
 #include "mlir/IR/Dialect.h"
 #include "mlir/IR/OpDefinition.h"
 #include "mlir/IR/OpImplementation.h"
 #include "mlir/Interfaces/CastInterfaces.h"
 #include "mlir/Interfaces/InferTypeOpInterface.h"
 #include "mlir/Interfaces/SideEffectInterfaces.h"
 #include "mlir/Interfaces/VectorInterfaces.h"
+#include "llvm/ADT/StringExtras.h"
 
 //===----------------------------------------------------------------------===//
 // ArithmeticDialect
 //===----------------------------------------------------------------------===//
 
 #include "mlir/Dialect/Arithmetic/IR/ArithmeticOpsDialect.h.inc"
 
 //===----------------------------------------------------------------------===//
 // Arithmetic Dialect Enum Attributes
 //===----------------------------------------------------------------------===//
 
 #include "mlir/Dialect/Arithmetic/IR/ArithmeticOpsEnums.h.inc"
+#define GET_ATTRDEF_CLASSES
+#include "mlir/Dialect/Arithmetic/IR/ArithmeticOpsAttributes.h.inc"
+
+//===----------------------------------------------------------------------===//
+// Arithmetic Interfaces
+//===----------------------------------------------------------------------===//
+#include "mlir/Dialect/Arithmetic/IR/ArithmeticOpsInterfaces.h.inc"
 
 //===----------------------------------------------------------------------===//
 // Arithmetic Dialect Operations
 //===----------------------------------------------------------------------===//
 
 #define GET_OP_CLASSES
 #include "mlir/Dialect/Arithmetic/IR/ArithmeticOps.h.inc"
 

mlir/include/mlir/Dialect/Arithmetic/IR/ArithmeticBase.td

let description = [{
     The arithmetic dialect is intended to hold basic integer and floating point
     mathematical operations. This includes unary, binary, and ternary arithmetic
     ops, bitwise and shift ops, cast ops, and compare ops. Operations in this
     dialect also accept vectors and tensors of integers or floats.
   }];
 
   let hasConstantMaterializer = 1;
   let emitAccessorPrefix = kEmitAccessorPrefix_Prefixed;
+  let useDefaultAttributePrinterParser = 1;
 }
 
 // The predicate indicates the type of the comparison to perform:
 // (un)orderedness, (in)equality and less/greater than (or equal to) as
 // well as predicates that are always true or false.
 def Arith_CmpFPredicateAttr : I64EnumAttr<
     "CmpFPredicate", "",
     [
def AtomicRMWKindAttr : I64EnumAttr<
     [ATOMIC_RMW_KIND_ADDF, ATOMIC_RMW_KIND_ADDI, ATOMIC_RMW_KIND_ASSIGN,
      ATOMIC_RMW_KIND_MAXF, ATOMIC_RMW_KIND_MAXS, ATOMIC_RMW_KIND_MAXU,
      ATOMIC_RMW_KIND_MINF, ATOMIC_RMW_KIND_MINS, ATOMIC_RMW_KIND_MINU,
      ATOMIC_RMW_KIND_MULF, ATOMIC_RMW_KIND_MULI, ATOMIC_RMW_KIND_ORI,
      ATOMIC_RMW_KIND_ANDI]> {
   let cppNamespace = "::mlir::arith";
 }
 
+def FASTMATH_NONE            : I32BitEnumAttrCaseNone<"none"      >;
+def FASTMATH_REASSOC         : I32BitEnumAttrCaseBit<"reassoc",  0>;
+def FASTMATH_NO_NANS         : I32BitEnumAttrCaseBit<"nnan",     1>;
+def FASTMATH_NO_INFS         : I32BitEnumAttrCaseBit<"ninf",     2>;
+def FASTMATH_NO_SIGNED_ZEROS : I32BitEnumAttrCaseBit<"nsz",      3>;
+def FASTMATH_ALLOW_RECIP     : I32BitEnumAttrCaseBit<"arcp",     4>;
+def FASTMATH_ALLOW_CONTRACT  : I32BitEnumAttrCaseBit<"contract", 5>;
+def FASTMATH_APPROX_FUNC     : I32BitEnumAttrCaseBit<"afn",      6>;
+def FASTMATH_FAST            : I32BitEnumAttrCaseGroup<
+    "fast",
+    [
+      FASTMATH_REASSOC,         FASTMATH_NO_NANS,     FASTMATH_NO_INFS,
+      FASTMATH_NO_SIGNED_ZEROS, FASTMATH_ALLOW_RECIP, FASTMATH_ALLOW_CONTRACT,
+      FASTMATH_APPROX_FUNC]>;
+
+def FastMathFlags : I32BitEnumAttr<
+    "FastMathFlags",
+    "Floating point fast math flags",
+    [
+      FASTMATH_NONE,           FASTMATH_REASSOC,         FASTMATH_NO_NANS,
+      FASTMATH_NO_INFS,        FASTMATH_NO_SIGNED_ZEROS, FASTMATH_ALLOW_RECIP,
+      FASTMATH_ALLOW_CONTRACT, FASTMATH_APPROX_FUNC,     FASTMATH_FAST]> {
+  let separator = ",";
+  let cppNamespace = "::mlir::arith";
+  let genSpecializedAttr = 0;
+  let printBitEnumPrimaryGroups = 1;
+}
+
 #endif // ARITHMETIC_BASE

mlir/include/mlir/Dialect/Arithmetic/IR/ArithmeticOps.td

 //===- ArithmeticOps.td - Arithmetic op definitions --------*- tablegen -*-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 #ifndef ARITHMETIC_OPS
 #define ARITHMETIC_OPS
 
 include "mlir/Dialect/Arithmetic/IR/ArithmeticBase.td"
+include "mlir/Dialect/Arithmetic/IR/ArithmeticOpsInterfaces.td"
 include "mlir/Interfaces/CastInterfaces.td"
 include "mlir/Interfaces/InferTypeOpInterface.td"
 include "mlir/Interfaces/SideEffectInterfaces.td"
 include "mlir/Interfaces/VectorInterfaces.td"
 include "mlir/IR/OpAsmInterface.td"
+include "mlir/IR/EnumAttr.td"
+
+def Arith_FastMathAttr :
+    EnumAttr<Arithmetic_Dialect, FastMathFlags, "fastmath"> {
+  let assemblyFormat = "`<` $value `>`";
+}
 
 // Base class for Arithmetic dialect ops. Ops in this dialect have no side
 // effects and can be applied element-wise to vectors and tensors.
 class Arith_Op<string mnemonic, list<Trait> traits = []> :
     Op<Arithmetic_Dialect, mnemonic, traits # [NoSideEffect,
     DeclareOpInterfaceMethods<VectorUnrollOpInterface>] #
     ElementwiseMappable.traits>;
 

 // Base class for integer binary operations.
 class Arith_IntBinaryOp<string mnemonic, list<Trait> traits = []> :
     Arith_BinaryOp<mnemonic, traits>,
     Arguments<(ins SignlessIntegerLike:$lhs, SignlessIntegerLike:$rhs)>,
     Results<(outs SignlessIntegerLike:$result)>;
 
 // Base class for floating point unary operations.
 class Arith_FloatUnaryOp<string mnemonic, list<Trait> traits = []> :
-    Arith_UnaryOp<mnemonic, traits>,
-    Arguments<(ins FloatLike:$operand)>,
-    Results<(outs FloatLike:$result)>;
+    Arith_UnaryOp<mnemonic,
+      !listconcat([DeclareOpInterfaceMethods<ArithFastMathInterface>],
+                  traits)>,
+    Arguments<(ins FloatLike:$operand,
+      DefaultValuedAttr<Arith_FastMathAttr, "FastMathFlags::none">:$fastmath)>,
+    Results<(outs FloatLike:$result)> {
+  let assemblyFormat = [{ $operand custom<ArithOpFloatAttrs>(attr-dict) `:`
+                          type($result) }];
+}
 
 // Base class for floating point binary operations.
 class Arith_FloatBinaryOp<string mnemonic, list<Trait> traits = []> :
-    Arith_BinaryOp<mnemonic, traits>,
-    Arguments<(ins FloatLike:$lhs, FloatLike:$rhs)>,
-    Results<(outs FloatLike:$result)>;
+    Arith_BinaryOp<mnemonic, 
+      !listconcat([DeclareOpInterfaceMethods<ArithFastMathInterface>],
+                  traits)>,
+    Arguments<(ins FloatLike:$lhs, FloatLike:$rhs,
+      DefaultValuedAttr<Arith_FastMathAttr, "FastMathFlags::none">:$fastmath)>,
+    Results<(outs FloatLike:$result)> {
+  let assemblyFormat = [{ $lhs `,` $rhs `` custom<ArithOpFloatAttrs>(attr-dict)
+                         `:` type($result) }];
+}
 
 // Base class for arithmetic cast operations. Requires a single operand and
 // result. If either is a shaped type, then the other must be of the same shape.
 class Arith_CastOp<string mnemonic, TypeConstraint From, TypeConstraint To,
                    list<Trait> traits = []> :
     Arith_Op<mnemonic, traits # [SameOperandsAndResultShape,
     DeclareOpInterfaceMethods<CastOpInterface>]>,
     Arguments<(ins From:$in)>,

mlir/include/mlir/Dialect/Arithmetic/IR/ArithmeticOpsInterfaces.td

+//===-- ArithmeticOpsInterfaces.td - arith op interfaces ---*- tablegen -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+//
+// This is the Arithmetic interfaces definition file.
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef ARITHMETIC_OPS_INTERFACES
+#define ARITHMETIC_OPS_INTERFACES
+
+include "mlir/IR/OpBase.td"
+
+def ArithFastMathInterface : OpInterface<"ArithFastMathInterface"> {
+  let description = [{
+    Access to operation fastmath flags.
+  }];
+
+  let cppNamespace = "::mlir::arith";
+
+  let methods = [
+    InterfaceMethod<
+      /*desc=*/        "Returns a FastMathFlagsAttr attribute for the operation",
+      /*returnType=*/  "FastMathFlagsAttr",
+      /*methodName=*/  "getFastMathFlagsAttr",
+      /*args=*/        (ins),
+      /*methodBody=*/  [{}],
+      /*defaultImpl=*/ [{
+        ConcreteOp op = cast<ConcreteOp>(this->getOperation());
+        return op.getFastmathAttr();
+      }]
+      >
+  ];
+}
+
+#endif // ARITHMETIC_OPS_INTERFACES
 No newline at end of file

mlir/include/mlir/Dialect/Arithmetic/IR/CMakeLists.txt

 set(LLVM_TARGET_DEFINITIONS ArithmeticOps.td)
 mlir_tablegen(ArithmeticOpsEnums.h.inc -gen-enum-decls)
 mlir_tablegen(ArithmeticOpsEnums.cpp.inc -gen-enum-defs)
+mlir_tablegen(ArithmeticOpsAttributes.h.inc -gen-attrdef-decls
+              -attrdefs-dialect=arith)
+mlir_tablegen(ArithmeticOpsAttributes.cpp.inc -gen-attrdef-defs
+              -attrdefs-dialect=arith)
 add_mlir_dialect(ArithmeticOps arith)
 add_mlir_doc(ArithmeticOps ArithmeticOps Dialects/ -gen-dialect-doc)
+
+set(LLVM_TARGET_DEFINITIONS ArithmeticOpsInterfaces.td)
+mlir_tablegen(ArithmeticOpsInterfaces.h.inc -gen-op-interface-decls)
+mlir_tablegen(ArithmeticOpsInterfaces.cpp.inc -gen-op-interface-defs)
+add_public_tablegen_target(MLIRArithmeticOpsInterfacesIncGen)

mlir/lib/Conversion/LLVMCommon/CMakeLists.txt

add_mlir_conversion_library(MLIRLLVMCommonConversion
   LINK_COMPONENTS
   Core
 
   LINK_LIBS PUBLIC
   MLIRIR
   MLIRLLVMIR
   MLIRSupport
   MLIRTransforms
+  MLIRArithmetic
   )

mlir/lib/Conversion/LLVMCommon/Pattern.cpp

 //===- Pattern.cpp - Conversion pattern to the LLVM dialect ---------------===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 #include "mlir/Conversion/LLVMCommon/Pattern.h"
+#include "mlir/Dialect/Arithmetic/IR/Arithmetic.h"
 #include "mlir/Dialect/LLVMIR/FunctionCallUtils.h"
 #include "mlir/Dialect/LLVMIR/LLVMDialect.h"
 #include "mlir/Dialect/LLVMIR/LLVMTypes.h"
 #include "mlir/IR/AffineMap.h"
 #include "mlir/IR/BuiltinAttributes.h"
 
 using namespace mlir;
 
+// Map arithmetic fastmath enum values to LLVMIR enum values.
+static auto convertArithFastMathFlagsToLLVM(arith::FastMathFlags arithFMF) {
+  LLVM::FastmathFlags llvmFMF{};
+  const std::pair<arith::FastMathFlags, LLVM::FastmathFlags> flags[] = {
+      {arith::FastMathFlags::nnan, LLVM::FastmathFlags::nnan},
+      {arith::FastMathFlags::ninf, LLVM::FastmathFlags::ninf},
+      {arith::FastMathFlags::nsz, LLVM::FastmathFlags::nsz},
+      {arith::FastMathFlags::arcp, LLVM::FastmathFlags::arcp},
+      {arith::FastMathFlags::contract, LLVM::FastmathFlags::contract},
+      {arith::FastMathFlags::afn, LLVM::FastmathFlags::afn},
+      {arith::FastMathFlags::reassoc, LLVM::FastmathFlags::reassoc}};
+  for (auto fmfMap : flags) {
+    if (bitEnumContains(arithFMF, fmfMap.first))
+      llvmFMF = llvmFMF | fmfMap.second;
+  }
+  return llvmFMF;
+}
+
+// Create an LLVM fastmath attribute from a given arithmetic fastmath attribute.
+static auto convertArithFastMathAttr(arith::FastMathFlagsAttr fmfAttr) {
+  auto arithFMF = fmfAttr.getValue();
+  auto llvmAttr = LLVM::FMFAttr::get(fmfAttr.getContext(),
+                                     convertArithFastMathFlagsToLLVM(arithFMF));
+  auto llvmAttrName = StringAttr::get(fmfAttr.getContext(), "fastmathFlags");
+  return NamedAttribute(llvmAttrName, llvmAttr);
+}
+
 //===----------------------------------------------------------------------===//
 // ConvertToLLVMPattern
 //===----------------------------------------------------------------------===//
 
 ConvertToLLVMPattern::ConvertToLLVMPattern(StringRef rootOpName,
                                            MLIRContext *context,
                                            LLVMTypeConverter &typeConverter,
                                            PatternBenefit benefit)
LogicalResult LLVM::detail::oneToOneRewrite(
 
   Type packedType;
   if (numResults != 0) {
     packedType = typeConverter.packFunctionResults(op->getResultTypes());
     if (!packedType)
       return failure();
   }
 
+  // Lower source op attributes to LLVM equivalents.
+  LLVM::detail::ConvertToLLVMAttributes attrConvert(op);
+
   // Create the operation through state since we don't know its C++ type.
   Operation *newOp =
       rewriter.create(op->getLoc(), rewriter.getStringAttr(targetOp), operands,
-                      packedType, op->getAttrs());
+                      packedType, attrConvert.getAttrs());
 
   // If the operation produced 0 or 1 result, return them immediately.
   if (numResults == 0)
     return rewriter.eraseOp(op), success();
   if (numResults == 1)
     return rewriter.replaceOp(op, newOp->getResult(0)), success();
 
   // Otherwise, it had been converted to an operation producing a structure.
   // Extract individual results from the structure and return them as list.
   SmallVector<Value, 4> results;
   results.reserve(numResults);
   for (unsigned i = 0; i < numResults; ++i) {
     auto type = typeConverter.convertType(op->getResult(i).getType());
     results.push_back(rewriter.create<LLVM::ExtractValueOp>(
         op->getLoc(), type, newOp->getResult(0), rewriter.getI64ArrayAttr(i)));
   }
   rewriter.replaceOp(op, results);
   return success();
 }
+
+/// Constructor for class to manage attributes when lowering to LLVMIR.
+/// Currently converts arithmetic fastmath flags to LLVM fastmath flags, and
+/// passes all other attributes through unmodified.
+LLVM::detail::ConvertToLLVMAttributes::ConvertToLLVMAttributes(Operation *op)
+    : srcAttrs(op->getAttrs()) {
+  if (auto fmi = dyn_cast<arith::ArithFastMathInterface>(*op)) {
+    auto arithFMFAttr = fmi.getFastMathFlagsAttr();
+    convertAttrs = AttrVector{};
+    for (auto &namedAttr : srcAttrs) {
+      convertAttrs.getValue().push_back(
+          (arithFMFAttr == namedAttr.getValue())
+              ? convertArithFastMathAttr(arithFMFAttr)
+              : namedAttr);
+    }
+  }
+}

mlir/lib/Conversion/LLVMCommon/VectorPattern.cpp

LogicalResult LLVM::detail::vectorOneToOneRewrite(
   if (!llvm::all_of(operands.getTypes(),
                     [](Type t) { return isCompatibleType(t); }))
     return failure();
 
   auto llvmNDVectorTy = operands[0].getType();
   if (!llvmNDVectorTy.isa<LLVM::LLVMArrayType>())
     return oneToOneRewrite(op, targetOp, operands, typeConverter, rewriter);
 
-  auto callback = [op, targetOp, &rewriter](Type llvm1DVectorTy,
+  // Lower source op attributes to LLVM equivalents.
+  LLVM::detail::ConvertToLLVMAttributes attrConvert(op);
+
+  auto callback = [op, targetOp, &attrConvert, &rewriter](Type llvm1DVectorTy,
                                                           ValueRange operands) {
     return rewriter
         .create(op->getLoc(), rewriter.getStringAttr(targetOp), operands,
-                llvm1DVectorTy, op->getAttrs())
+                llvm1DVectorTy, attrConvert.getAttrs())
         ->getResult(0);
   };
 
   return handleMultidimensionalVectors(op, operands, typeConverter, callback,
                                        rewriter);
 }

mlir/lib/Dialect/Arithmetic/IR/ArithmeticDialect.cpp

 //===- ArithmeticDialect.cpp - MLIR Arithmetic dialect implementation -----===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 #include "mlir/Dialect/Arithmetic/IR/Arithmetic.h"
 #include "mlir/IR/Builders.h"
+#include "mlir/IR/DialectImplementation.h"
 #include "mlir/Transforms/InliningUtils.h"
+#include "llvm/ADT/TypeSwitch.h"
 
 using namespace mlir;
 using namespace mlir::arith;
 
 #include "mlir/Dialect/Arithmetic/IR/ArithmeticOpsDialect.cpp.inc"
+#include "mlir/Dialect/Arithmetic/IR/ArithmeticOpsInterfaces.cpp.inc"
+#define GET_ATTRDEF_CLASSES
+#include "mlir/Dialect/Arithmetic/IR/ArithmeticOpsAttributes.cpp.inc"
 
 namespace {
 /// This class defines the interface for handling inlining for arithmetic
 /// dialect operations.
 struct ArithmeticInlinerInterface : public DialectInlinerInterface {
   using DialectInlinerInterface::DialectInlinerInterface;
 
   /// All arithmetic dialect ops can be inlined.
   bool isLegalToInline(Operation *, Region *, bool,
                        BlockAndValueMapping &) const final {
     return true;
   }
 };
 } // namespace
 
 void arith::ArithmeticDialect::initialize() {
   addOperations<
 #define GET_OP_LIST
 #include "mlir/Dialect/Arithmetic/IR/ArithmeticOps.cpp.inc"
       >();
+  addAttributes<
+#define GET_ATTRDEF_LIST
+#include "mlir/Dialect/Arithmetic/IR/ArithmeticOpsAttributes.cpp.inc"
+      >();
   addInterfaces<ArithmeticInlinerInterface>();
 }
 
 /// Materialize an integer or floating point constant.
 Operation *arith::ArithmeticDialect::materializeConstant(OpBuilder &builder,
                                                          Attribute value,
                                                          Type type,
                                                          Location loc) {
   return builder.create<arith::ConstantOp>(loc, value, type);
 }

mlir/lib/Dialect/Arithmetic/IR/ArithmeticOps.cpp

 #include "llvm/ADT/SmallString.h"
 
 #include "llvm/ADT/APSInt.h"
 
 using namespace mlir;
 using namespace mlir::arith;
 
 //===----------------------------------------------------------------------===//
+// Floating point op parse/print helpers
+//===----------------------------------------------------------------------===//
+static ParseResult parseArithOpFloatAttrs(OpAsmParser &parser,
+                                          NamedAttrList &result) {
+  return parser.parseOptionalAttrDict(result);
+}
+
+static void printArithOpFloatAttrs(OpAsmPrinter &printer, Operation *op,
+                                   DictionaryAttr attrs) {
+  auto fmi = dyn_cast<arith::ArithFastMathInterface>(*op);
+  assert(fmi && "arith custom attribute printer assumes fastmath interface");
+  SmallVector<StringRef, 1> elidedAttrs;
+  auto arithFMAttr = fmi.getFastMathFlagsAttr();
+  // Elide printing the fastmath attribute for null attributes as well as
+  // fastmath="none" values.
+  if (!arithFMAttr || (arithFMAttr.getValue() == FastMathFlags::none))
+    elidedAttrs.push_back("fastmath");
+  auto pos = printer.getStream().tell();
+  printer.printOptionalAttrDict(attrs.getValue(), elidedAttrs);
+  // Add a trailing space, but only if attribute printing (after any eliding
+  // above) actually resulted in stream output.
+  if (printer.getStream().tell() != pos)
+    printer << ' ';
+}
+
+//===----------------------------------------------------------------------===//
 // Pattern helpers
 //===----------------------------------------------------------------------===//
 
 static IntegerAttr addIntegerAttrs(PatternRewriter &builder, Value res,
                                    Attribute lhs, Attribute rhs) {
   return builder.getIntegerAttr(res.getType(),
                                 lhs.cast<IntegerAttr>().getInt() +
                                     rhs.cast<IntegerAttr>().getInt());

mlir/lib/Dialect/Arithmetic/IR/CMakeLists.txt

 set(LLVM_TARGET_DEFINITIONS ArithmeticCanonicalization.td)
 mlir_tablegen(ArithmeticCanonicalization.inc -gen-rewriters)
 add_public_tablegen_target(MLIRArithmeticCanonicalizationIncGen)
 
 add_mlir_dialect_library(MLIRArithmetic
   ArithmeticOps.cpp
   ArithmeticDialect.cpp
 
   ADDITIONAL_HEADER_DIRS
   ${MLIR_MAIN_INCLUDE_DIR}/mlir/Dialect/Arithmetic
 
   DEPENDS
   MLIRArithmeticOpsIncGen
+  MLIRArithmeticOpsInterfacesIncGen
 
   LINK_LIBS PUBLIC
   MLIRDialect
   MLIRInferTypeOpInterface
   MLIRIR
   )

mlir/test/Conversion/ArithmeticToLLVM/arith-to-llvm.mlir

 // -----
 
 // CHECK-LABEL: @select
 func.func @select(%arg0 : i1, %arg1 : i32, %arg2 : i32) -> i32 {
   // CHECK: = llvm.select %arg0, %arg1, %arg2 : i1, i32
   %0 = arith.select %arg0, %arg1, %arg2 : i32
   return %0 : i32
 }
+
+// CHECK-LABEL: @fastmath
+func.func @fastmath(%arg0: f32, %arg1: f32, %arg2: i32) {
+// CHECK: {{.*}} = llvm.fadd %arg0, %arg1  {fastmathFlags = #llvm.fastmath<fast>} : f32
+// CHECK: {{.*}} = llvm.fmul %arg0, %arg1  {fastmathFlags = #llvm.fastmath<fast>} : f32
+// CHECK: {{.*}} = llvm.fneg %arg0  {fastmathFlags = #llvm.fastmath<fast>} : f32
+// CHECK: {{.*}} = llvm.fadd %arg0, %arg1  : f32
+// CHECK: {{.*}} = llvm.fadd %arg0, %arg1  {fastmathFlags = #llvm.fastmath<nnan, ninf>} : f32
+  %0 = arith.addf %arg0, %arg1 {fastmath = #arith.fastmath<fast>} : f32
+  %1 = arith.mulf %arg0, %arg1 {fastmath = #arith.fastmath<fast>} : f32
+  %2 = arith.negf %arg0 {fastmath = #arith.fastmath<fast>} : f32
+  %3 = arith.addf %arg0, %arg1 {fastmath = #arith.fastmath<none>} : f32
+  %4 = arith.addf %arg0, %arg1 {fastmath = #arith.fastmath<nnan,ninf>} : f32
+  return
+}

mlir/test/Dialect/Arithmetic/ops.mlir

func.func @minimum(%v1: vector<4xf32>, %v2: vector<4xf32>,
                %i1: i32, %i2: i32) {
   %min_vector = arith.minf %v1, %v2 : vector<4xf32>
   %min_scalable_vector = arith.minf %sv1, %sv2 : vector<[4]xf32>
   %min_float = arith.minf %f1, %f2 : f32
   %min_signed = arith.minsi %i1, %i2 : i32
   %min_unsigned = arith.minui %i1, %i2 : i32
   return
 }
+
+// CHECK-LABEL: @fastmath
+func.func @fastmath(%arg0: f32, %arg1: f32, %arg2: i32) {
+// CHECK: {{.*}} = arith.addf %arg0, %arg1 {fastmath = #arith.fastmath<fast>} : f32
+// CHECK: {{.*}} = arith.subf %arg0, %arg1 {fastmath = #arith.fastmath<fast>} : f32
+// CHECK: {{.*}} = arith.mulf %arg0, %arg1 {fastmath = #arith.fastmath<fast>} : f32
+// CHECK: {{.*}} = arith.divf %arg0, %arg1 {fastmath = #arith.fastmath<fast>} : f32
+// CHECK: {{.*}} = arith.remf %arg0, %arg1 {fastmath = #arith.fastmath<fast>} : f32
+// CHECK: {{.*}} = arith.negf %arg0 {fastmath = #arith.fastmath<fast>} : f32
+  %0 = arith.addf %arg0, %arg1 {fastmath = #arith.fastmath<fast>} : f32
+  %1 = arith.subf %arg0, %arg1 {fastmath = #arith.fastmath<fast>} : f32
+  %2 = arith.mulf %arg0, %arg1 {fastmath = #arith.fastmath<fast>} : f32
+  %3 = arith.divf %arg0, %arg1 {fastmath = #arith.fastmath<fast>} : f32
+  %4 = arith.remf %arg0, %arg1 {fastmath = #arith.fastmath<fast>} : f32
+  %5 = arith.negf %arg0 {fastmath = #arith.fastmath<fast>} : f32
+// CHECK: {{.*}} = arith.addf %arg0, %arg1 : f32
+  %6 = arith.addf %arg0, %arg1 {fastmath = #arith.fastmath<none>} : f32
+// CHECK: {{.*}} = arith.addf %arg0, %arg1 {fastmath = #arith.fastmath<nnan,ninf>} : f32
+  %7 = arith.addf %arg0, %arg1 {fastmath = #arith.fastmath<nnan,ninf>} : f32
+// CHECK: {{.*}} = arith.mulf %arg0, %arg1 {fastmath = #arith.fastmath<fast>} : f32
+  %8 = arith.mulf %arg0, %arg1 {fastmath = #arith.fastmath<reassoc,nnan,ninf,nsz,arcp,contract,afn>} : f32
+
+  return
+}

mlir/tools/mlir-tblgen/OpPythonBindingGen.cpp

for (int i = 0, e = op.getNumArgs(); i < e; ++i) {
 
     // Unit attributes are handled specially.
     if (attribute->attr.getStorageType().trim().equals("::mlir::UnitAttr")) {
       builderLines.push_back(llvm::formatv(initUnitAttributeTemplate,
                                            attribute->name, argNames[i]));
       continue;
     }
 
-    builderLines.push_back(llvm::formatv(attribute->attr.isOptional()
-                                             ? initOptionalAttributeTemplate
-                                             : initAttributeTemplate,
-                                         attribute->name, argNames[i]));
+    builderLines.push_back(llvm::formatv(
+        attribute->attr.isOptional() || attribute->attr.hasDefaultValue()
   }
 }
 
 /// Populates `builderLines` with additional lines that are required in the
 /// builder to set up successors. successorArgNames is expected to correspond
 /// to the Python argument name for each successor on the op.
 static void populateBuilderLinesSuccessors(
     const Operator &op, llvm::ArrayRef<std::string> successorArgNames,