meheff
commented
1 year ago Given the complexity of the op it's not clear that handling it like other operations in the delay model makes sense. If you're actually building hardware I'm sure you'd slot in some divider IP of some kind so if a divide actually hits the codegen stage it should probably be an error but perhaps the error message could be better. However I can envision instances where you just want the verilog and don't care if div/mod is modeled exactly right. To support this you could have a couple features:
- A set of ops which generate an error when they hit codegen (error something like: "Cannot emit verilog for op..."). It would have div and mod by default but would be user overridable.
- Some made up delay model for div/mod. Maybe the same delay as a multiplier.
The following IR results in "Unhandled node for delay estimation in delay model 'sky130': smod" at code gen:
top fn test(i: bits[32]) -> bits[32] { literal.2: bits[32] = literal(value=2, id=2, pos=[(1,2,5)]) smod.3: bits[32] = smod(i, literal.2, id=3, pos=[(1,2,5)]) literal.4: bits[32] = literal(value=3, id=4, pos=[(1,3,5)]) ret add.5: bits[32] = add(smod.3, literal.4, id=5, pos=[(1,3,5)]) }
Suggest adding, refining delay model for smod (and any other non-covered ir operants for successful code generation).
Example: test.ir.txt runme.sh.txt