Allow custom ops with static constant input edges

[ss2165]

Discussed in #1342

^{Originally posted by ss2165 July 24, 2024}
This follows discussions mainly in #1308

A constant static input to an op would would be some semantically significant data, that cannot be lost like metadata. This could be thought of as "literal properties" or "intrinsic parameters".

If further we can elevate values to constants at compile time (constexpr evaluation) we can do powerful things with ops that need some structured, complicated, compile-time known data.

An open question is whether this data is available to binary compute_signature functions.

[doug-q]

An open question is whether this data is available to binary compute_signature functions.

Currently compute_signature takes [TypeParam] -> PolyFuncType. I suggest that with this change it should take [TypeParam] -> ([Type], PolyFuncType), where the list [Type] specifies the number, order, and types of required static input edges. Ideally any in vars the list should resolve in the scope of the type params inside the PolyFuncType.

With the feature as described it is not allowed for extension operations to take Function edges from FuncDefn/FuncDecl, because those edges are polymorphic, unlike the Static edges from Const nodes. The following change would lift this restriction:

Rename LoadFunction to TypeApply. Currently LoadFunction has a single output Value edge. Change this to a Const edge.

[acl-cqc]

Rename LoadFunction to TypeApply. Currently LoadFunction has a single output Value edge. Change this to a Const edge.

So LoadFunction is now static-function to static-const. This can wire into a LoadConstant if you want a Value e.g. if the successor of your LoadFunction was an IndirectCall. Neat.

Call still takes Function and does type-apply itself? Or, how about we continue the same line and make Call take a Value input so could be applied only to (1) a Const or (2) a TypeApply of a FuncDefn?

[doug-q]

Call still takes Function and does type-apply itself? Or, how about we continue the same line and make Call take a Value input so could be applied only to (1) a Const or (2) a TypeApply of a FuncDefn?

I think you mean "Call take a Const input". Yes you could do this, with the advantage that now only TypeApply applies type args to functions. You could also leave Call as is for convenience, and add CallConst that takes a Const edge.

[acl-cqc]

Yes, Call takes Const not Function, sorry!

[ss2165]

With the feature as described it is not allowed for extension operations to take Function edges from FuncDefn/FuncDecl

This is the case in the PR linked above. I like the change you propose but I think that is a follow up feature so should be in a new issue.

[ss2165]

Moved to hugr "v2" model work #1433