This is an archive of the discontinued LLVM Phabricator instance.

[Support] Add OpauqeDataStore
AbandonedPublic

Authored by beanz on Mar 24 2022, 2:10 PM.

Details

Reviewers
rnk
lhames
MaskRay
Summary

There are places in LLVM where data needs to be communicated between
layers that lack a good place to store the data. This leads to leaky
abstractions, or sometimes just using void*.

This data type can provide a type-safe alternative. The OpaqueDataStore
stores elements by type and can regurgitate them on demand. The object
holding the OpaqueDataStore requires no visibility to the types stored
within it, the classes for the stored data are only required to be
available at the points where the data is accessed.

I intend to use this in a subsequent patch to attach data to the
LLVMContext from inside the DirectX backend. The data being attached
should have the same lifetime as the LLVMContext, does not invalidate
(unless the context is destroyed), and should not be part of the IR
library.

Diff Detail

Event Timeline

beanz created this revision.Mar 24 2022, 2:10 PM
beanz requested review of this revision.Mar 24 2022, 2:10 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 24 2022, 2:10 PM
dblaikie added inline comments.
llvm/include/llvm/Support/OpaqueDataStore.h
70

I'd probably go with a C++ style cast, to be clear what conversions are happening here.

115

Is storage of multiple items necessary, or could this be more like std::any? (could we use std::any instead of adding this new thing?)

This is like a heterogeneous list in FP. I also wonder whether we should use llvm::Any instead. We cannot use C++17 std::any yet.
(Also, llvm::Any has the LLVM_EXTERNAL_VISIBILITY trick. I don't know how std::any behaves in various STL implementations in the presence of LLVM_LINK_LLVM_DYLIB)

beanz added a comment.Mar 28 2022, 9:50 AM

@dblaikie I think you make a fair point. My use case really only needs to store a single object, so I can use llvm::Any instead. I had been trying to find a more generally useful mechanism, but without a second use case in mind llvm::Any will suffice. I'll update the downstream patch today and abandon this.

beanz abandoned this revision.Mar 28 2022, 11:13 AM

Dropping for now in favor of llvm::Any in the subsequent patches.