search for: eestat

Displaying 3 results from an estimated 3 matches for "eestat".

Did you mean: estat
2013 Nov 01
0
[LLVMdev] [Proposal] Adding callback mechanism to Execution Engines
Unless I'm missing something, indeed addGlobalMapping should not work with MCJIT. MCJIT does not consult EEState.getGlobalAddressMap when resolving symbols. Instead it uses RTDyldMemoryManager::getSymbolAddress which checks with DynamicLibrary::SearchForAddressOfSymbol, so Andy's suggestion of DynamicLibrary::addSymbol is better as it should work with both JIT and MCJIT. Another options is to use the La...
2013 Nov 01
2
[LLVMdev] [Proposal] Adding callback mechanism to Execution Engines
Hi Andrew, I used the latest code from trunk. GlobalSymbolTable is being used in MCJIT. I guess it wasn't clear from the proposal that the user program will be modified to indicate that the callback should happen at that point in the code. The objective is to call some of the functions which belong to lli or the ExecutionEngine. Thanks, Sumeeth On Fri, Nov 1, 2013 at 5:40 PM, Kaylor,
2013 Apr 04
0
[LLVMdev] ExecutionEngine::updateGlobalMapping
...o the nature of the analysis pass, there can be several calls to updateGlobalMapping with the same GlobalValue key and the same (or sometimes different) address. My problem is when the reverse mapping is enabled, the following fragment: // If we are using the reverse mapping, add it too. if (!EEState.getGlobalAddressReverseMap(locked).empty()) { AssertingVH<const GlobalValue> &V = EEState.getGlobalAddressReverseMap(locked)[Addr]; assert((V == 0 || GV == 0) && "GlobalMapping already established!"); V = GV; } Will assert even though the update of...