Sharing: Allow larger units to replace smaller ones

[rachitnigam]

A 32 bit adder can perform 16-bit adds. A 16-bit register can shore 8-bits of information. Share ‘em.

obviously needs some attribute-based knowledge of the primitives.

[sampsyo]

Cool idea. And yeah, it could be special-cased just for std_add, for example, or it could rely on an attribute like @shareable("add") or whatever to indicate what "class" of shareable things it belongs to.

[rachitnigam]

@calebmkim any thoughts on how hard this would be to implement? Maybe we can make this a part of the sharing paper?

[calebmkim]

It seems like there are two main things for this.

1. The renaming of cells can no longer be arbitrary-- we would have to rename to the largest width adder.
2. Any time we write to/read from the inputs/outputs of a shared adder, we would have to be slice by the appropriate number of bits.

I think something like this should be done in two stages. We can first do 1) by modifying the way we "color" the graph for adders. Each time we color (i.e., rename) a given adder, we should record that that adder needs to be sliced and by how much. This can possibly be done by the attribute idea you guys already mentioned. Then we can do 2) by just going through the entire program and introducing std_slice. Overall, I don't see anything that would be too challenging, although it won't necessarily be easy either.

[rachitnigam]

Ah, interesting point. One way to rephrase your suggestion is having a “bit width strengthening” pass that makes small units bigger and slices their outputs. After that, resource Shari by can just do its magic

[rachitnigam]

It also occurs to me that much like resource sharing in general, this is only worth doing for large, non-combinational resources like dividers. We also need some way for the component to specify which parameter represents the WIDTH-like parameter

[rachitnigam]

@calebmkim's study of sharing behavior has revealed that this is probably a bad idea. Closing this for now