MLIR attributes only attach to operations, not SSA values. However, in our compilation flow, we regularly want to attach attributes to individual channels (here defined as one use of an SSA value i.e., an mlir::OpOperand). For example, in the context of buffer placement, individual channels may have specific buffering properties which need to be stored in the IR.
We already have partial support for associating attributes to channels as part of the buffer placement infrastructure. Here, channel-specific buffering properties are internally stored in a handshake::OpBufPropsAttr attribute--itself a map from result index to handshake::ChannelBufPropsAttr--attached to the operation that produces the corresponding SSA value. Dynamatic already contains abstractions that present those attributes as if they were really attached to SSA values rather than operations and handle attribute storage automatically in the background. This buffer placement-specific logic should be
[x] generalized to work with any attribute that should semantically attach to a channel,
[x] moved to the Support folder, and
[x] modified so that the attribute related to a channel is attached to the consumer operation (i.e., the one that has the SSA value as operand) instead of the producer operation (current implementation). This is motivated by the fact that a dematerialized IR (i.e., where SSA values are not used exactly once) is occasionally easier to work with yet does not interact well with such producer-operation-owned channel attributes; indeed, in the situation where an SSA value is used more than once, it prevents us from storing more than one version of the attribute for the SSA value. Attaching one version of the attribute to the owner of each SSA value use resolves this issue. This makes no semantic difference for materialized IRs where every SSA value has exactly one use.
MLIR attributes only attach to operations, not SSA values. However, in our compilation flow, we regularly want to attach attributes to individual channels (here defined as one use of an SSA value i.e., an
mlir::OpOperand). For example, in the context of buffer placement, individual channels may have specific buffering properties which need to be stored in the IR.We already have partial support for associating attributes to channels as part of the buffer placement infrastructure. Here, channel-specific buffering properties are internally stored in a
handshake::OpBufPropsAttrattribute--itself a map from result index tohandshake::ChannelBufPropsAttr--attached to the operation that produces the corresponding SSA value. Dynamatic already contains abstractions that present those attributes as if they were really attached to SSA values rather than operations and handle attribute storage automatically in the background. This buffer placement-specific logic should be