[Calyx] Binary Floating Point MulF Operator

[jiahanxie353]

Add support for floating point multiplication in Calyx

[rachitnigam]

Okay, I think we should move the floating point operators into their own separate definition because they are so much more complicated. Can we get the syntax: calyx.ieee754.add and calyx.ieee754.mul working instead of adding the floating-point operations directly into the same namespace as everything else?

[jiahanxie353]

marking ready for review again!

[jiahanxie353]

Please add a CHECK-NEXT: for this line.

wait it is added here right? I believe you are looking for std_mulFN_0 = std_mulFN(8, 24, 32)?

[rachitnigam]

Ah, can this not use CHECK-NEXT since we know exactly which line produces the primitive?

[jiahanxie353]

you mean we don't need to check std_mulFN_0 = std_mulFN(8, 24, 32) at all?

[rachitnigam]

No, can we ensure that the code is generated precisely as a consequence of that one line?

[jiahanxie353]

Sounds good, I'm updating to CHECK-DAG to ensure your request of checking the code is generated by the correct line sequentially; as well as avoiding checking some boilerplate code that will be otherwise generated by CHECK-NEXT. Please let me know if it makes sense.

[cgyurgyik]

A few smaller comments.

[cgyurgyik]

Nit: isn't the better way to do this is remove the .ieee754 prefix for any F operations?

[jiahanxie353]

The entire prefix + name is calyx.ieee754.add/calyx.ieee754.mul, removing ieee754 will simply become add/mul; but we want std_addFN/std_mulFN after emitting to Calyx native compiler.

[cgyurgyik]

More concretely, I think there is a better way to do this than manually write a new if statement for each floating point operation. It'd be nice to avoid this every time:

if (std::is_same<calyx::<MyNewFloatingPointOp, TLibraryOP>::value)
  name = "std_MyNewFloatingPointOp";

Ideally, since we're already distinguishing them without a _std prefix, we could infer this is some floating point operation, and then check what standard it conforms too.

/// Returns the technical floating point this operation conforms to, e.g., "ieee754"
/// (This should probably be an enum, which is subsequently converted to a string.)
std::string standard() { ... }

if (auto fOp = dyn_cast<FloatingPointOp>(op)):
  name.remove(llvm::join(".", fOp.standard()));
  name.prepend("std_");

(I'm not saying you should spend a lot of time doing this, it is a mere suggestion. In general, I do think the conforming technical standard of a floating point operation should be a field of the op so it can referenced during pattern rewrites.)

[jiahanxie353]

I've thought about this, I don't think it's worth it now.
In the foreseeable future, only IEEE754 floating point is integrated; and moreover, only Add and Mul are present in the Berkeley HardFloat.
My opinion is we can address future needs and refactor the code when there is an actual, concrete need.
But I totally get what you are saying.

[jiahanxie353]

Sorry, let me take it back.
When doing some research on the floating point comparison issue #7821, I found Berkeley HardFloat has division, square root, and comparisons as well.
So I definitely need to use a better design to incorporate all of these calyx::FloatingPointOps, as you suggested.

[cgyurgyik]

Same here.