Dynamic Constant Math

Adding dynamic constant math to Hercules.

• IR definitions
• Parsing (what syntax do people like for the IR? I used a prefix function notation like +(x, y) but this doesn't necessarily fit well with the syntax of the rest of the IR)
• Type checking

Marked as Draft until I implement Juno code-gen for dynamic constant math.

requested review from @rarbore2

assigned to @aaronjc4

added 1 commit

• 660b193e - Implement dynamic constant expression code-gen for Juno

Compare with previous version

I think the prefix syntax actually does fit well with the IR syntax, where basically everything syntactically is a function func(arg1, arg2, ...). I'm ok with using +, -, *, / in DC math, since that will just be when parsing DCs.

One thing I've been wondering is about whether we need to constrain divides - i.e. we definitely need to add a constraint for every -(a, b) that a >= b, since DCs are non-negative. Nominally, we also need for every /(a, b) that b divides a, but we could also just commit to rounding a/b up or down, depending on whichever is more useful. The use case I'm thinking of is tiling with leftovers on a dimension (i.e. non-trivial strip mining, in which case we'd also need a rem % operator).

added 1 commit

• 29d969f6 - Fixes to dynamic constant generation from Juno

Compare with previous version

I'm open to adding remainder if you think we should. We could just define division to be integer rounding (so towards 0) which is probably more useful for the tiling with leftovers example

marked this merge request as ready

marked this merge request as draft

@rarbore2 There are some parts of the new code-gen that need to be fixed to work with the changes to dynamic constants. Do you want to do that now or should I just add a todo!() case in those places?

It appears to just be one place, in compile_dynamic_constant.

So compile_dynamic_constant should already be set up to have DC math added to it with relative ease. Are the aforementioned changes to DCs adding math ops (+, -, ...), or did the underlying representation change more fundamentally?

It's just adding math ops (so there's a match with missing cases now).

Then we should add the codegen for that here. I can add those tonight (on this branch) if you'd like.

Sure, that would be great. Thanks

Done

added 3 commits

• 29d969f6...cce484b6 - 2 commits from branch main
• b98e2a33 - Merge branch 'main' into dyn_const_math

Compare with previous version

added 1 commit

• 614207d1 - Compile dynamic constant math to sched IR

Compare with previous version

approved this merge request

added 3 commits

• 614207d1...6f8168f1 - 2 commits from branch main
• 16cf6452 - Merge branch 'main' into dyn_const_math

Compare with previous version

marked this merge request as ready

mentioned in commit def3de91

merged