Skip to content
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

[ORC] Implement basic reoptimization. #67050

Merged
merged 3 commits into from
Apr 26, 2024
Merged

[ORC] Implement basic reoptimization. #67050

merged 3 commits into from
Apr 26, 2024

Conversation

sunho
Copy link
Member

@sunho sunho commented Sep 21, 2023

No description provided.

@llvmbot llvmbot added clang Clang issues not falling into any other category compiler-rt clang:codegen labels Sep 21, 2023
@sunho sunho requested a review from lhames September 21, 2023 20:17
Copy link
Contributor

@lhames lhames left a comment

Choose a reason for hiding this comment

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

Just reviewing the RedirectionManager interface and implementation patch for now. I have some minor comments, but otherwise this is looking amazing -- thank you very much @sunho!

Comment on lines 89 to 91
for (auto [K, V] : InitialDests) {
Flags[K] = V.getFlags();
}
Copy link
Contributor

Choose a reason for hiding this comment

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

No braces needed for single-line loops. :)

Comment on lines 22 to 27
if (auto Err = JD.define(std::make_unique<RedirectableMaterializationUnit>(
*this, InitialDests),
RT))
return Err;

return Error::success();
Copy link
Contributor

Choose a reason for hiding this comment

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

This could just be:

  return JD.define(std::make_unique<RedirectableMaterializationUnit>(*this, InitialDests), RT);

R->failMaterialization();
return;
}
dbgs() << *K << "\n";
Copy link
Contributor

Choose a reason for hiding this comment

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

Stray debugging output?

Comment on lines 48 to 59
if (auto Err = R->replace(absoluteSymbols(NewSymbolDefs))) {
ES.reportError(std::move(Err));
R->failMaterialization();
return;
}

if (auto Err = redirectInner(TargetJD, InitialDests)) {
ES.reportError(std::move(Err));
R->failMaterialization();
return;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

I think the call to redirectInner should precede the call to replace: As soon as replace runs anyone waiting on NewSymbolDefs will be notified that those symbols are available, but they're not actually usable until the call to redirectInner, right?

You should also return the stubs to the pool on all three of the failure paths (or add a FIXME that we should do that in the future).

Comment on lines 88 to 91
if (auto Err = ES.getExecutorProcessControl().getMemoryAccess().writePointers(
PtrWrites))
return Err;
return Error::success();
Copy link
Contributor

Choose a reason for hiding this comment

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

This could just be:

return ES.getExecutorProcessControl().getMemoryAccess().writePointers(PtrWrites);

Comment on lines 103 to 139
SymbolLookupSet LookupSymbols;
DenseMap<SymbolStringPtr, ExecutorSymbolDef *> NewDefsMap;

Triple TT = ES.getTargetTriple();
auto G = std::make_unique<jitlink::LinkGraph>(
"<INDIRECT STUBS>", TT, TT.isArch64Bit() ? 8 : 4,
TT.isLittleEndian() ? support::little : support::big,
jitlink::getGenericEdgeKindName);
auto &PointerSection =
G->createSection(StubPtrTableName, MemProt::Write | MemProt::Read);
auto &StubsSection =
G->createSection(JumpStubTableName, MemProt::Exec | MemProt::Read);

for (size_t I = OldSize; I < NewSize; I++) {
auto Pointer = AnonymousPtrCreator(*G, PointerSection, nullptr, 0);
if (auto Err = Pointer.takeError())
return Err;

StringRef PtrSymName = StubPtrSymbolName(I);
Pointer->setName(PtrSymName);
Pointer->setScope(jitlink::Scope::Default);
LookupSymbols.add(ES.intern(PtrSymName));
NewDefsMap[ES.intern(PtrSymName)] = &StubPointers[I];

auto Stub = PtrJumpStubCreator(*G, StubsSection, *Pointer);
if (auto Err = Stub.takeError())
return Err;

StringRef JumpStubSymName = JumpStubSymbolName(I);
Stub->setName(JumpStubSymName);
Stub->setScope(jitlink::Scope::Default);
LookupSymbols.add(ES.intern(JumpStubSymName));
NewDefsMap[ES.intern(JumpStubSymName)] = &JumpStubs[I];
}
Copy link
Contributor

Choose a reason for hiding this comment

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

We only need one anchor symbol to trigger emission of the graph. Eventually I think this could be sped up by emitting:

.section <JumpStubTableName>
__<JumpStubTableName>.<++Idx>:
  ... stubs ...
.section <StubPtrTableName>
__<StubPtrTableName>.<Idx>:
  ... ptrs ...

Then looking up __JumpStubTableName.<Idx> and __StubPtrTableName.<Idx> and using the stub and pointer sizes to stride through the resulting addresses.

I don't think this change needs to happen before the commit though -- you could add a FIXME and this can be handled in the future.

namespace llvm {
namespace orc {

class IRPartitionLayer : public IRLayer {
Copy link
Contributor

Choose a reason for hiding this comment

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

It'd be good to add a class comment explaining the layer's behavior. (I know the file comment covers this, but people looking up the type docs may not see that).

Comment on lines +13 to +14
#ifndef LLVM_EXECUTIONENGINE_ORC_JITLINKREDIRECABLEMANAGER_H
#define LLVM_EXECUTIONENGINE_ORC_JITLINKREDIRECABLEMANAGER_H
Copy link
Contributor

Choose a reason for hiding this comment

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

Include guard should be LLVM_EXECUTIONENGINE_ORC_JITLINKREDIRECABLESYMBOLMANAGER_H.

Copy link
Contributor

@lhames lhames left a comment

Choose a reason for hiding this comment

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

Minor comments aside: LGTM!

Comment on lines 12 to 13
#ifndef LLVM_EXECUTIONENGINE_ORC_REOPTLAYER_H
#define LLVM_EXECUTIONENGINE_ORC_REOPTLAYER_H
Copy link
Contributor

Choose a reason for hiding this comment

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

Include guard should be LLVM_EXECUTIONENGINE_ORC_REOPTIMIZELAYER_H to match the file name.

namespace llvm {
namespace orc {

using ReOptMaterializationUnitID = uint64_t;
Copy link
Contributor

Choose a reason for hiding this comment

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

Use of this type seems to be contained within the ReOptimizeLayer -- could it be a member of that class?

@sunho sunho merged commit 0d288e5 into llvm:main Apr 26, 2024
3 of 4 checks passed
nikic added a commit that referenced this pull request Apr 26, 2024
@nikic
Copy link
Contributor

nikic commented Apr 26, 2024

I've reverted this to fix build failures -- it looks like this has been implemented against a very old LLVM version.

@sunho
Copy link
Member Author

sunho commented Apr 26, 2024

Thanks for reverting the commit. Let me fix build error shortly.

/// Registers reoptimize runtime dispatch handlers to given PlatformJD. The
/// reoptimization request will not be handled if dispatch handler is not
/// registered by using this function.
Error reigsterRuntimeFunctions(JITDylib &PlatformJD);
Copy link

Choose a reason for hiding this comment

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

Typo: reigsterRuntimeFunctions -> registerRuntimeFunctions

@Thrrreeee
Copy link

Thanks for reverting the commit. Let me fix build error shortly.

Hi @sunho
Could you please let me know how the progress on the code modification is going and approximately how much longer it will take to complete?

@sunho
Copy link
Member Author

sunho commented Jun 7, 2024

@Thrrreeee Oh this has been forgotten. It should be a trivial fix. Let me try to reland it tmr.

@Thrrreeee
Copy link

Hi @sunho,
I have some questions. For example, in the reoptimization layer, we need to obtain profile information. How can we profile JITed code and then perform PGO? It doesn't seem like this is the case with the ORC JIT yet.
I know that there are JITlisntener to support Perf to profile JITed code, but how can we use it in PRC JIT? Dynamic instrumentation or use other profiler to get profile information?Could you tell me your plan?

@Thrrreeee
Copy link

Thrrreeee commented Jun 16, 2024

Let me try to reland it tmr.

Hi @sunho, Have you finished this?

@sunho
Copy link
Member Author

sunho commented Oct 11, 2024

Some build bots are breaking because we are running runtime JIT execution unit tests on unsupported targets. Investigating this issue right now.

@sunho
Copy link
Member Author

sunho commented Oct 11, 2024

Relanded on 188ede2

@sunho
Copy link
Member Author

sunho commented Oct 12, 2024

Failing at https://lab.llvm.org/buildbot/#/builders/161/builds/2692. Probably wise to disable to test on the COFF-ARM64.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clang:codegen clang Clang issues not falling into any other category compiler-rt
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants