This is an archive of the discontinued LLVM Phabricator instance.

[mlir] Extern constant via ElementsAttr.
Needs RevisionPublic

Authored by jpienaar on Mar 30 2022, 4:22 PM.

Details

Reviewers
mehdi_amini
Summary

Simple example of using ElementsAttr interface to implement a constant
value not uniqued in the context and whose lifetime is not guaranteed by
the context. This effectively results in the pointer to the data being
uniqued rather than the data. But it can be used as regular
ElementsAttr.

Example behavior is to lose "extern'ness" on round tripping through
textual format. Chose this as my expectation is that extern constant
would be used as part of workflow that manages state, but the moment one
outputs to textual format you have left that.

Diff Detail

Event Timeline

jpienaar created this revision.Mar 30 2022, 4:22 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 30 2022, 4:22 PM
jpienaar requested review of this revision.Mar 30 2022, 4:22 PM

Chose this as my expectation is that extern constant would be used as part of workflow that manages state, but the moment one outputs to textual format you have left that.

I have strong concerns with this: even if there is some external state, the IR should round-trip as much as possible..
So instead I'd like to see a system where we would be able round-trip whatever ID is used to interact with the runtime to access the constant (it can be a name or other means of ID).
Of course that means that you can't just get a pointer to this attribute alone and get the data without some indirection, but that can be also handled by the Dialect class itself for example.

Chose this as my expectation is that extern constant would be used as part of workflow that manages state, but the moment one outputs to textual format you have left that.

I have strong concerns with this: even if there is some external state, the IR should round-trip as much as possible..

This roundtrips except for location in memory values are stored (but that's true for regular elements attributes too) and whether equal values are deduped or not (which would result in changing equality checks indeed). I could add the textual format so that equal values but with different backing storage are not equal and so preserve the non-deduped nature. The life time difference cannot appear in any valid program and is pre-requisite of use.

So instead I'd like to see a system where we would be able round-trip whatever ID is used to interact with the runtime to access the constant (it can be a name or other means of ID).

Would you want attributes fixed to particular runtimes? Or you'd want all runtimes to implement some interface? I was thinking primarily of easy interop with runtimes that are unaware of MLIR, so no changes to runtimes, no knowledge about allocating memory (e.g., when parsing), requirements are the MLIR context doesn't outlive backing storage and no mutation to the backing state during MLIR passes (which for some runtimes would require that one bumps the ref count on the "tensor", which means the MLIR importer side needs to be aware of the runtime semantics but its kept to edges at least). Materialization should be avoided during actual optimizations/transformations but is not explicitly avoided by any means but you'd have to explicitly convert the attribute to another attribute though, so it wouldn't be accidental. [and to be clear, I don't expect this actual instance to be used with any real runtime :)]

I'd expect rather this would go another way: you'd be having a framework specific input that decides what kind of attribute to create (e.g., if parsing for mobile you may avoid making any dense elementrs attributes with more than 4 elements actually in context and rather try and keep them extern referring to flatbuffer directly). The textual debugging format and its printing & parsing is just for testing as normal, and the decision of how and where to store constants is not grouped in with that (e.g., not link debugging format to runtime).

mehdi_amini requested changes to this revision.Apr 1 2022, 8:40 PM

Chose this as my expectation is that extern constant would be used as part of workflow that manages state, but the moment one outputs to textual format you have left that.

I have strong concerns with this: even if there is some external state, the IR should round-trip as much as possible..

This roundtrips except for location in memory values are stored (but that's true for regular elements attributes too) and whether equal values are deduped or not (which would result in changing equality checks indeed). I could add the textual format so that equal values but with different backing storage are not equal and so preserve the non-deduped nature.

Got it: it seems that you're preserving more than I thought here. I still think that even if you're using a DenseIntElementsAttr when parsing back (for the storage), you should likely still produce a TestExtern1DI64Elements instance using the pointer to these data, otherwise an op defined as having a TestExtern1DI64Elements in ODS would fail the verifier when parsing back I think (can you add printing/parsing tests in your test?).

You also have a point about the pointer equality changing, which can be addressed by printing the pointer as extra "key" for the unification in the context?

The life time difference cannot appear in any valid program and is pre-requisite of use.

Right.

So instead I'd like to see a system where we would be able round-trip whatever ID is used to interact with the runtime to access the constant (it can be a name or other means of ID).

Would you want attributes fixed to particular runtimes? Or you'd want all runtimes to implement some interface? I was thinking primarily of easy interop with runtimes [...]

Yeah, actually I think you're actually on the right path here!

Something I've been looking in the past was going one step further by also to have the dialect having a possible callback into the runtime to allocate memory so that folding constant could also be externalized.

This revision now requires changes to proceed.Apr 1 2022, 8:40 PM