Add packing design doc to the HEIR website#2296
Add packing design doc to the HEIR website#2296copybara-service[bot] merged 1 commit intogoogle:mainfrom
Conversation
|
@asraa Ready for review! |
| attribute, and produces the same data-semantic type. This is an "entry point" | ||
| into the layout system and lowers to a loop that packs the data according to | ||
| the layout. |
There was a problem hiding this comment.
| attribute, and produces the same data-semantic type. This is an "entry point" | |
| into the layout system and lowers to a loop that packs the data according to | |
| the layout. | |
| attribute, and produces the same data-semantic type. This is an "entry point" into the layout system | |
| for cleartext values and lowers to a loop that packs the data according to the layout. |
Actually I just wanted to understand this clearly just to double check. Cleartext values that are block args will also be assign_layout'd too right? (i.e. we won't annotate the block arg with a layout)
There was a problem hiding this comment.
"Blocks" don't have the ability to annotate by themselves, you can only annotate the owning op.
But, for example, cleartext function arguments will be assigned a layout, and it won't be until we add the preprocessing helper that we can move them to the client.
There was a problem hiding this comment.
Ah I didn't mean annotate the block arg but annotate the arg on the owning op (the func or generic)
And it seems like the rest of the doc only annotated cleartext func args if they're used in a ctxt op
| The [`layout-optimization`](/docs/passes/#-layout-optimization) pass has two | ||
| main goals: to choose better kernels for ops, and to try to eliminate | ||
| `convert_layout` ops. It does this by running a backward pass through the IR. If | ||
| it encounters an op that is followed by a `convert_layout` op, it attempts to | ||
| hoist the `convert_layout` through the op to its arguments. |
There was a problem hiding this comment.
I've also added an initial forward pass too! Ah! I guess I can update that after. But the forward pass would start by pushing the initial default layouts through the ops as much as possible (assuming the cost of the kernel does not increase in doing so).
For example, in the case of the slice insertion, we'll pick the best kernel on the forward pass because it'll be cheaper to choose the slice insertion result to minimize the layout conversion needed to insert the slice.
Honestly, now I'm thinking I should just make that be part of layout-propagation (and modify the assigned destination layout during the forward pass if it only has one use)
Migrate some remaining TODOs to dedicated issues
j2kun
added
the
pull_ready
2 participants
Fixes #1888
Fixes #913