This is an archive of the discontinued LLVM Phabricator instance.

[ORC] Add a NonOwningSymbolStringPtr utility.
ClosedPublic

Authored by lhames on Jan 22 2023, 10:46 AM.

Details

Summary

Introduces a non-owning SymbolStringPool entry pointer. Instances of the new
type can be compared with SymbolStringPtr instances, but do not participate in
ref-counting and are therefore cheaper to copy. This makes it efficient to use
in algorithms that use symbol-strings as ids, e.g. ORC's waiting-on graph. A
future commit will rewrite ORC's waiting-on graph.

Diff Detail

Event Timeline

lhames created this revision.Jan 22 2023, 10:46 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 22 2023, 10:46 AM
lhames requested review of this revision.Jan 22 2023, 10:46 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 22 2023, 10:46 AM
dblaikie added inline comments.Jan 22 2023, 9:36 PM
llvm/include/llvm/ExecutionEngine/Orc/SymbolStringPool.h
51–55

Could this be private and friended to the test class, rather than only in +Asserts? (that way it'd be tested in non-Asserts, and not callable from code/accidentally used in +Asserts builds in the rest of the code)

90–91

If these things are only sizeof(void*) then maybe pass by value, rather than const ref?

lhames added inline comments.Jan 22 2023, 10:17 PM
llvm/include/llvm/ExecutionEngine/Orc/SymbolStringPool.h
51–55

Ahh -- I was thinking of using this in assertions (and the tests), but wanted to discourage use outside that. To get the best of both worlds I could take your suggestion and make getRefCount private, then introduce a new method:

#ifndef NDEBUG
  bool isPoolEntryValid() const { return getRefCount(); }
#endif
90–91

They could be pass by value. Is there likely to be any benefit on a trivially inline-able method like this? Or is it mostly a style issue?

lhames updated this revision to Diff 491956.Jan 24 2023, 4:30 PM

Address review feedback.

dblaikie added inline comments.Jan 24 2023, 10:30 PM
llvm/include/llvm/ExecutionEngine/Orc/SymbolStringPool.h
51–55

Ah, fair enough - sounds good :)

Hmm, could the debugging/testing use cases be covered by the private member anyway?

248

Hmm, wouldn't this be non-NDEBUG conditional? (since it's declared unconditionally and called unconditionally from the test code now?)

llvm/unittests/ExecutionEngine/Orc/SymbolStringPoolTest.cpp
25–31

Do you need these locals anymore, now that you have an SP member?

lhames updated this revision to Diff 493683.Jan 31 2023, 11:08 AM

Address latest feedback.

lhames marked 2 inline comments as done.Jan 31 2023, 11:11 AM
lhames added inline comments.
llvm/include/llvm/ExecutionEngine/Orc/SymbolStringPool.h
51–55

Yep -- that's the approach used in the latest patch.

llvm/unittests/ExecutionEngine/Orc/SymbolStringPoolTest.cpp
25–31

Nope -- just missed those lines in the cleanup. Thanks for catching that!

dblaikie accepted this revision.Jan 31 2023, 1:41 PM

Sure, looks good

llvm/include/llvm/ExecutionEngine/Orc/SymbolStringPool.h
90–91

general guideline - maybe makes -O0 builds slightly less bad

llvm/unittests/ExecutionEngine/Orc/SymbolStringPoolTest.cpp
20–22

Awkward to have to wrap the API like this - but I guess the inconvenience of having to touch the class definition for every test to do this http://google.github.io/googletest/reference/testing.html#FRIEND_TEST is annoying too.

This revision is now accepted and ready to land.Jan 31 2023, 1:41 PM
This revision was landed with ongoing or failed builds.Jan 31 2023, 2:28 PM
This revision was automatically updated to reflect the committed changes.
lhames marked 2 inline comments as done.