[poly]: `heir-polynomial-to-llvm` sometimes requires 128-bit math, should have the option to avoid it

The naive lowering of poly to llvm can require 128-bit ops if the cmod is bigger than 32 bits (i.e., two 64-bit ints required to represent a coefficient, which get multiplied to a 128-bit result before being modded back to cmod).

Some platforms and architectures don't have 128-bit math intrinsics, and when this project's tests use mlir-cpu-runner on such a platform, it fails with a message like this before exiting.

JIT session error: Symbols not found: [ __modti3 ]

(modti3) is the intrinsic for 128-bit integer division.

It seems reasonable that (even if this test weren't failing on Google's internal CI :wink:) we should allow this pass to emulate wide-int ops with lower-width intrinsics. This is supported by MLIR via the -emulate-wide-int pass. However, that pass happens to not support arith.subi at the moment, which our lowering uses. So I commented out the test that used 128-bit math in https://github.com/google/heir/pull/203 and we can add it back after upstreaming support for subi.

Adding it would involve something like this in heir-opt.cpp, with some additional plumbing to allow the user to specify their platform's widest supported int.

  arith::ArithEmulateWideIntOptions emulateWideIntOptions;
  emulateWideIntOptions.widestIntSupported = 64;
  manager.addPass(arith::createArithEmulateWideInt(emulateWideIntOptions));

google / heir

[poly]: `heir-polynomial-to-llvm` sometimes requires 128-bit math, should have the option to avoid it #220