This is an archive of the discontinued LLVM Phabricator instance.

[mlir] Remove TypedAttr and ElementsAttr from DenseArrayAttr
ClosedPublic

Authored by Mogball on Nov 7 2022, 8:22 PM.

Details

Summary

This patch removes the implementation of TypedAttr and ElementsAttr
from DenseArrayAttr and, in doing so, removes the need store a shaped
type. The attribute now stores a size (number of elements), an MLIR type
as a discriminator, and a raw byte array.

The intent of DenseArrayAttr was not to be a drop-in replacement for DenseElementsAttr. It was meant to be a simple container of integers or floats that map to C++ types. The ElementsAttr implementation on DenseArrayAttr had many holes in it, and fixing those holes would require evolving DenseArrayAttr in a way that is incompatible with its original purpose.

Diff Detail

Event Timeline

Mogball created this revision.Nov 7 2022, 8:22 PM
Herald added a project: Restricted Project. · View Herald Transcript
Mogball requested review of this revision.Nov 7 2022, 8:22 PM
rriddle added a comment.EditedNov 8 2022, 1:11 PM

I think some users are already relying on DenseArrayAttr implementing ElementsAttr. What's the plan for them? Would it be better to sever the dependency on ShapedType from ElementsAttr? That would still allow for the type simplifications on DenseArrayAttr.

I would be very surprised if any user was finding the DenseArrayAttr ElementsAttr implementation useful, beyond storing an ElementsAttr and dyn_cast'ing to DenseElementsAttr, DenseResourceAttr, DenseArrayAttr, etc. My understanding is that most clients are using one of the base classes, which are not impacted by this change.

However, a follow up patch will introduce an ArrayElementsAttr that is backed by a DenseArrayAttr and provide the full ElementsAttr API

rriddle added a comment.EditedNov 8 2022, 4:45 PM

I would be very surprised if any user was finding the DenseArrayAttr ElementsAttr implementation useful, beyond storing an ElementsAttr and dyn_cast'ing to DenseElementsAttr, DenseResourceAttr, DenseArrayAttr, etc. My understanding is that most clients are using one of the base classes, which are not impacted by this change.

However, a follow up patch will introduce an ArrayElementsAttr that is backed by a DenseArrayAttr and provide the full ElementsAttr API

They are using ElementsAttr as the constraint on the op class, which would be broken directly by this change.

They are using ElementsAttr as the constraint on the op class, which would be broken directly by this change.

Mind elaborating on this? I don't quite get how we got a dependency on ElementsAttr so fast for DenseArrayAttr?

They are using ElementsAttr as the constraint on the op class, which would be broken directly by this change.

Mind elaborating on this? I don't quite get how we got a dependency on ElementsAttr so fast for DenseArrayAttr?

E.g. https://github.com/tensorflow/tensorflow/blob/dba3770a39ef1d69c3b0156338e7cbe3902e4177/tensorflow/compiler/mlir/tosa/transforms/legalize_tf.cc#L804

(The op being created with that attribute expects an ElementsAttr)

Various other users have been switching over from DenseElementsAttr to DenseArrayAttr. Not saying the changes here aren't welcome, but we should have a pretty
clear path of the evolution going on to prevent back and forth churn for users. I would also hope for a small in between path for those that have already switched.

They are using ElementsAttr as the constraint on the op class, which would be broken directly by this change.

Mind elaborating on this? I don't quite get how we got a dependency on ElementsAttr so fast for DenseArrayAttr?

E.g. https://github.com/tensorflow/tensorflow/blob/dba3770a39ef1d69c3b0156338e7cbe3902e4177/tensorflow/compiler/mlir/tosa/transforms/legalize_tf.cc#L804

Thanks!
(and... errrr.... UH!)

Various other users have been switching over from DenseElementsAttr to DenseArrayAttr. Not saying the changes here aren't welcome, but we should have a pretty
clear path of the evolution going on to prevent back and forth churn for users. I would also hope for a small in between path for those that have already switched.

Can they just go back to DenseElementsAttr? I'm not clear on the path forward right now but these usages don't seem desirable to me (ArrayElementsAttr seems speculative to me still).

rriddle added a comment.EditedNov 8 2022, 5:30 PM

They are using ElementsAttr as the constraint on the op class, which would be broken directly by this change.

Mind elaborating on this? I don't quite get how we got a dependency on ElementsAttr so fast for DenseArrayAttr?

E.g. https://github.com/tensorflow/tensorflow/blob/dba3770a39ef1d69c3b0156338e7cbe3902e4177/tensorflow/compiler/mlir/tosa/transforms/legalize_tf.cc#L804

Thanks!
(and... errrr.... UH!)

Various other users have been switching over from DenseElementsAttr to DenseArrayAttr. Not saying the changes here aren't welcome, but we should have a pretty
clear path of the evolution going on to prevent back and forth churn for users. I would also hope for a small in between path for those that have already switched.

Can they just go back to DenseElementsAttr? I'm not clear on the path forward right now but these usages don't seem desirable to me (ArrayElementsAttr seems speculative to me still).

Likely, in which case I'd be fine with this change (with the direction of what to do in the commit description). At this point we could likely just remove the auto-splatting from DenseElementsAttr, and direct users to prefer resources for "large" things.

At this point we could likely just remove the auto-splatting from DenseElementsAttr, and direct users to prefer resources for "large" things.

DenseResourceAttr doesn't solve the problem of encoding repeated elements many times in the IR. We should split SplatElementsAttr out from DenseElementsAttr in that case, but the latter still has bit packing whereas DenseArrayAttr (and it's ElementsAttr derivative) does not

rriddle added a comment.EditedNov 8 2022, 7:08 PM

At this point we could likely just remove the auto-splatting from DenseElementsAttr, and direct users to prefer resources for "large" things.

DenseResourceAttr doesn't solve the problem of encoding repeated elements many times in the IR. We should split SplatElementsAttr out from DenseElementsAttr in that case, but the latter still has bit packing whereas DenseArrayAttr (and it's ElementsAttr derivative) does not

That's a semi orthogonal problem which has various potential solutions (we shouldn't be detecting huge splats at all at runtime, users should be responsible for knowing if they have a splat or not to some degree). I'd be fine with just removing all of the "undesirable" behavior of DenseElementsAttr -> remove bitpacking, split out splat, etc.

rriddle accepted this revision.Nov 9 2022, 2:01 PM

Hitting approve because I forgot to, and my only real concern is about evolving DenseElementsAttr/communicating the intent with users.

This revision is now accepted and ready to land.Nov 9 2022, 2:01 PM
Mogball edited the summary of this revision. (Show Details)Dec 5 2022, 1:27 PM
This revision was landed with ongoing or failed builds.Dec 5 2022, 1:28 PM
This revision was automatically updated to reflect the committed changes.