search for: updatepoint

Displaying 12 results from an estimated 12 matches for "updatepoint".

Did you mean: updatepointer
2016 Jul 28
2
[ORC JIT] Exposing IndirectStubsManager from CompileOnDemandLayer.h
...his already been added? Would it be possible to merge this in? diff --git a/CompileOnDemandLayer.h b/CompileOnDemandLayer.h index bd192b8..4aa3362 100644 --- a/CompileOnDemandLayer.h +++ b/CompileOnDemandLayer.h @@ -429,6 +429,28 @@ private: return CalledAddr; } +public: + TargetAddress updatePointer(std::string FuncName, TargetAddress FnBodyAddr) { + //Find out which logical dylib contains our symbol + auto LDI = LogicalDylibs.begin(); + for (auto LDE = LogicalDylibs.end(); LDI != LDE; ++LDI) { + if (auto LMResources = LDI->getLogicalModuleResourcesForSymbol(FuncName, fals...
2016 Jul 29
0
[ORC JIT] Exposing IndirectStubsManager from CompileOnDemandLayer.h
...e this in? > > diff --git a/CompileOnDemandLayer.h b/CompileOnDemandLayer.h > index bd192b8..4aa3362 100644 > --- a/CompileOnDemandLayer.h > +++ b/CompileOnDemandLayer.h > @@ -429,6 +429,28 @@ private: > return CalledAddr; > } > > +public: > + TargetAddress updatePointer(std::string FuncName, TargetAddress > FnBodyAddr) { > + //Find out which logical dylib contains our symbol > + auto LDI = LogicalDylibs.begin(); > + for (auto LDE = LogicalDylibs.end(); LDI != LDE; ++LDI) { > + if (auto LMResources = > LDI->getLogicalModuleRes...
2016 Jul 29
2
[ORC JIT] Exposing IndirectStubsManager from CompileOnDemandLayer.h
...mpileOnDemandLayer.h b/CompileOnDemandLayer.h >> index bd192b8..4aa3362 100644 >> --- a/CompileOnDemandLayer.h >> +++ b/CompileOnDemandLayer.h >> @@ -429,6 +429,28 @@ private: >> return CalledAddr; >> } >> >> +public: >> + TargetAddress updatePointer(std::string FuncName, TargetAddress >> FnBodyAddr) { >> + //Find out which logical dylib contains our symbol >> + auto LDI = LogicalDylibs.begin(); >> + for (auto LDE = LogicalDylibs.end(); LDI != LDE; ++LDI) { >> + if (auto LMResources = >> LDI...
2016 Jul 29
0
[ORC JIT] Exposing IndirectStubsManager from CompileOnDemandLayer.h
...ndLayer.h >>> index bd192b8..4aa3362 100644 >>> --- a/CompileOnDemandLayer.h >>> +++ b/CompileOnDemandLayer.h >>> @@ -429,6 +429,28 @@ private: >>> return CalledAddr; >>> } >>> >>> +public: >>> + TargetAddress updatePointer(std::string FuncName, TargetAddress >>> FnBodyAddr) { >>> + //Find out which logical dylib contains our symbol >>> + auto LDI = LogicalDylibs.begin(); >>> + for (auto LDE = LogicalDylibs.end(); LDI != LDE; ++LDI) { >>> + if (auto LMReso...
2016 Jul 30
1
[ORC JIT] Exposing IndirectStubsManager from CompileOnDemandLayer.h
...92b8..4aa3362 100644 >>>> --- a/CompileOnDemandLayer.h >>>> +++ b/CompileOnDemandLayer.h >>>> @@ -429,6 +429,28 @@ private: >>>> return CalledAddr; >>>> } >>>> >>>> +public: >>>> + TargetAddress updatePointer(std::string FuncName, TargetAddress >>>> FnBodyAddr) { >>>> + //Find out which logical dylib contains our symbol >>>> + auto LDI = LogicalDylibs.begin(); >>>> + for (auto LDE = LogicalDylibs.end(); LDI != LDE; ++LDI) { >>>> +...
2016 May 27
1
How to recompile functions with ORC JIT?
.... As Dave implied, it depends on how you've set up your ORC stack. These days, the API directly responsible for this is the IndirectStubsManager (see llvm/include/llvm/ExecutionEngine/Orc/IndirectionUtils.h). If you have access to the appropriate IndirectStubsManager you just need to call the updatePointer method with the name of the function you want to update and the new address. If you're using the CompileOnDemand layer to compile lazily from IR, the problem is that that layer doesn't (currently) expose the IndirectStubManager for each module. I think it would be reasonable to add suppo...
2016 May 27
0
How to recompile functions with ORC JIT?
+Lang Ultravague answer: There are a few different Orc layers for different levels of indirection needed for different levels of substitutability. One way is to indirect every call through global function pointers - so when you want to replace the function you write the new function pointer to the global variable. I forget which layers do which kinds of indirection. - Dave On Thu, May 26, 2016
2019 Sep 03
2
SourceMgr vs EXPENSIVE_CHECKS
...; *, std::__debug::vector<unsigned short, std::allocator<unsigned short> > *, std::__debug::vector<unsigned int, std::allocator<unsigned int> > *, std::__debug::vector<unsigned long, std::allocator<unsigned long> > *> >' requested here Value = Info::updatePointer(0, PtrVal); ^ /home/jayfoad2/git/llvm-project/llvm/include/llvm/ADT/PointerUnion.h:227:15: note: in instantiation of member function 'llvm::PointerIntPair<void *, 2, int, llvm::pointer_union_detail::PointerUnionUIntTraits<std::__debug::vector<unsigned char, std::allocator...
2019 Sep 03
2
SourceMgr vs EXPENSIVE_CHECKS
...; short, std::allocator<unsigned short> > *, >> std::__debug::vector<unsigned int, std::allocator<unsigned int> > *, >> std::__debug::vector<unsigned long, std::allocator<unsigned long> > *> >> >' requested here >> Value = Info::updatePointer(0, PtrVal); >> ^ >> /home/jayfoad2/git/llvm-project/llvm/include/llvm/ADT/PointerUnion.h:227:15: >> note: in instantiation of member function 'llvm::PointerIntPair<void >> *, 2, int, llvm::pointer_union_detail::PointerUnionUIntTraits<std::__debug::vec...
2019 Oct 02
2
SourceMgr vs EXPENSIVE_CHECKS
...short> > *, >> >> std::__debug::vector<unsigned int, std::allocator<unsigned int> > *, >> >> std::__debug::vector<unsigned long, std::allocator<unsigned long> > *> >> >> >' requested here >> >> Value = Info::updatePointer(0, PtrVal); >> >> ^ >> >> /home/jayfoad2/git/llvm-project/llvm/include/llvm/ADT/PointerUnion.h:227:15: >> >> note: in instantiation of member function 'llvm::PointerIntPair<void >> >> *, 2, int, llvm::pointer_union_detail::Pointer...
2016 May 27
2
How to recompile functions with ORC JIT?
Hello, I am trying to figure out how to recompile functions multiple times during run-time with ORC JIT and I'd appreciate any help/advice. My use case is t he following: every time a function of interest (annotated) is called, profiling data are gathered. Given enough data the function is recompiled using different optimizations. This happens repeatedly until the "best"
2018 Apr 05
1
llvm::PointerIntPair -- is this by design or a bug?
I do agree that sign-extension is the right thing to do. Unlike bit-fields, llvm::PointerIntPair has asserts checking that the int value is within range. So if you assign an out of range value, it should fail with an assertion: llvm::PointerIntPair<SomeType*, 3, int> pip; pip.setInt(7); // can be made to fail as the valid range // of signed 3-bit values is [-4:3] The above