Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[CAS] Add LLVMCAS library with InMemoryCAS implementation #114096

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

cachemeifyoucan
Copy link
Collaborator

Add llvm::cas::ObjectStore abstraction and InMemoryCAS as a in-memory
CAS object store implementation.

The ObjectStore models its objects as:

  • Content: An array of bytes for the data to be stored.
  • Refs: An array of references to other objects in the ObjectStore.
    And each CAS Object can be idenfied with an unqine ID/Hash.

ObjectStore supports following general action:

  • Expected store(Content, ArrayRef)
  • Expected get(ID)

It also introduces following types to interact with a CAS ObjectStore:

  • CASID: Hash representation for an CAS Objects with its context to help
    print/compare CASIDs.
  • ObjectRef: A light-weight ref for an object in the ObjectStore. It is
    implementation defined so it can be optimized for
    read/store/references depending on the implementation.
  • ObjectProxy: A proxy for the users of CAS to interact with the data
    inside CAS Object. It bundles a ObjectHandle and an ObjectStore
    instance.

Created using spr 1.3.5
Copy link
Contributor

@ilovepi ilovepi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a large patch, so I haven't read all the C++ closely enough to say anything about it. Mostly, I've left comments on the documentation, and pointed out a few things I saw while skimming the implementation.

I think overall a bit more explanation about how some of the key classes interoperate may be warranted. For instance I really don't understand why some of the reinterpret casts should be legal in InMemroyInlineObject.

The other thing I see is a pattern of foo(){return fooImpl();}, but fooImpl() isn't private or (from what I can see) an extension point. I'm not sure I understand the design choice here, since I don't recall seeing it used this way much in LLVM. Normally the Impls are either private, virtual, or in some other module/namespace. It's a big project, so maybe I've just missed something though.

I'll try to take a more detailed look at the implementation code, but I'd encourage others to look too, since this is a very large, complicated patch set.

Created using spr 1.3.5
Created using spr 1.3.5
Copy link
Contributor

@rastogishubham rastogishubham left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Everything LGTM!

Created using spr 1.3.5
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants