Reduce SymbolStringPtr copies.

[lhames]

ExecutionSession::lookup currently makes several copies of the SymbolStringPtrs involved in the lookup. As of f9aef47 they're present in at least the AsynchronousSymbolQuery and the InProgressLookupSet::LookupSet member. They're also at least partially duplicated in the DefGeneratorCandidates and DefGeneratorNonCandidates sets of InProgressLookupSet.

If we introduced a new SymbolStringWeakPtr class (and probably a weakly-referencing version of LookupSet built on top of it), we could probably avoid many of these copies.

Note: Naming the weakly-referencing LookupSet will be an interesting exercise: We need to disambiguate weak reference (in the shared-ptr sense) of symbol strings and weak reference (in the linker sense) of symbols. Maybe SymbolStringUnsafePtr would be better? Or SymbolStringUnretainedPtr?

[llvmbot]

@llvm/issue-subscribers-orcjit

[lhames]

More potentially unnecessary SymbolStringPtr copies: EPCDynamicLibrarySearchGenerator::tryToGenerate is copying SymbolStringPtrs to build the lookup set that it will pass to ExecutorProcessControl::lookupSymbols, but the lookupSymbols method could probably be rewritten to use StringRefs instead. If that's the case we could save the copies here.

[lhames]

JITDylib's MaterializingInfosMap and UnmaterializedInfosMap members could be keyed on SymbolStringWeakPtr -- their entries should be a subset of the entries in the main symbol table.

[lhames]

We could probably use SymbolStringWeakPtrs in the symbol-dependence graph too. That would be a big win: copies in the dep graph will be a relatively common operation.