Initial glue for poly.constant (iss #97)

[ljhsiun2]

Test currently doesn't work (as proposed in #97, or I'm writing it wrong), need to figure out if a custom parser is needed.

Glue is currently just a placeholder to get things to compile.

CC @j2kun

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[j2kun]

I put a comment somehwere but now I can't find it so I'll repeat it here: the following patch shows the "right" syntax.

-    %poly3 = "poly.constant"() <{ coefficients = dense<[2, 2, 5]> : tensor<3xi32> }> : !poly.poly<#ring1> : () -> !poly.poly<#ring1>
+    %poly3 = "poly.constant"() {coefficients = array<i32: 2, 2, 5>} : () -> !poly.poly<#ring1>

I had to learn about the difference between properties (which is new as of 2023) and attributes. I didn't intend to use properites, which is the <{ }> notation, while { } is the attribute notation.

I also found that when I switch from properties to attributes as above, but left the value as dense<[2, 2, 5]> I got an error that it claimed the value wasn't a dense I32 Array, which is silly. I looked up the source for the DenseI32ArrayAttr and saw that this array<i32: 2, 2, 5> was the "generic" form of the attribute, and it looks like other ops that have a simpler format all use a custom parser/printer. We could do that too, if the generic form is too cumbersome.

[j2kun]

Also see the very timely PR #124 which seems to opt us out of a migration to use properties as the default. If you're interested in digging into how to use properties instead of attributes, feel free to flip that flag back after it lands.

[ljhsiun2]

Btw work is a bit hectic currently but I am still looking at this in my downtime, so sorry on the delays. If it's really necessary soon someone else can pick it up.

Another noob question-- how can one look at the generated verilog here? Trying to run --emit-verilog works for the poly dialect.

[j2kun]

No rush! Right now the verilog generator is a pretty special purpose pass that we used for some prototype lowerings. To get it to work with poly, we'd need to lower poly to upstream MLIR dialects, which is ongoing work in, e.g., #134.

[j2kun]

This is moving upstream to MLIR, so closing.