search for: remotememorymanag

...I think it's possible that the clang optimizations are just exposing a timing-related vulnerability in the pipe handling. -Andy From: Renato Golin [mailto:renato.golin at linaro.org] Sent: Tuesday, November 26, 2013 1:30 AM To: NAKAMURA Takumi Cc: Kaylor, Andrew; LLVM Dev Subject: Re: MCJIT RemoteMemoryManager Failures on ARM On 26 November 2013 01:55, NAKAMURA Takumi <geek4civic at gmail.com<mailto:geek4civic at gmail.com>> wrote: IMHO, tests may be suppressed with lit.local.cfg, only if; They were disabled, but then re-enabled because they don't fail on normal build bots, but they d...

IMHO, tests may be suppressed with lit.local.cfg, only if; - The issue is filed -- PR18057 - There is at least one person responsible to watch on this issue. Suppression is not good idea. But it should be done anyways if responsible person were there. I would not help you since I don't have any arm boxes. Thank you. 2013/11/26 Renato Golin <renato.golin at linaro.org>: > Hi

On 26 November 2013 01:55, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > IMHO, tests may be suppressed with lit.local.cfg, only if; > They were disabled, but then re-enabled because they don't fail on normal build bots, but they do on self-host bots. So, I think this is a more serious issue than just MCJIT, I think this is a Clang miscompilation. I'll try on x86 to see

...test case completely independent of any of significant part of LLVM (unless the failure is entirely timing dependent). Thanks, Andy From: Renato Golin [mailto:renato.golin at linaro.org] Sent: Tuesday, November 26, 2013 2:44 PM To: Kaylor, Andrew Cc: NAKAMURA Takumi; LLVM Dev Subject: Re: MCJIT RemoteMemoryManager Failures on ARM On 26 November 2013 19:05, Kaylor, Andrew <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>> wrote: I would also note that the failure isn't actually in anything MCJIT-specific. Aside from the fact that it seems to be clang-specific, the code that is...

Hi Andrew & Takumi, I'm including you guys because you seem to know what should and what shouldn't work, given your recent changes to the XFAILs. Feel free to exclude yourselves, or include other folks. I'm having a problem with a self-hosting ARM bot described here: http://llvm.org/bugs/show_bug.cgi?id=18057 Basically, allocateSpace() sometimes works, sometimes doesn't. I

On 26 November 2013 19:05, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > I would also note that the failure isn’t actually in anything > MCJIT-specific. Aside from the fact that it seems to be clang-specific, > the code that is failing is specific to the lli remote implementation. > It’s not clear to me why it would fail under aggressive optimization with > clang,

...>Host and Target Triples are same and the host architecture is in the >supported list. There isn't anything in MCJIT as far as I know that prevents cross compilation. That said, the SectionMemoryManager that's used by the unit tests doesn't support remote execution. However, the RemoteMemoryManager has been improving lately; it could foreseeably be used to add remote execution support to the tests.

...> Yes, that is one of the intended use models for MCJIT. > > > > If you look at the source for ‘lli’ you’ll find an option called > “remote-mcjit” which does exactly this (for testing purposes). > > > > The key function (which in the lli case is called from lli’s > RemoteMemoryManager::notifyObjectLoaded method) is > ExecutionEngine::mapSectionAddress. This function tells MCJIT to reapply > relocations to the loaded object as if it were loaded at a different > address in memory than it actually is. The client is responsible for the > particulars of allocating mem...

A need has arisen to generate code using MCJIT but not in the target process instead in a different process (and possibly even different machine though not in the scope). Reading through the tutorials and MCJIT design document, it seems like this is possible or was kept in mind during design of MCJIT. How do I achieve this? Are there examples? Dave -------------- next part -------------- An

Thanks Dan! The ArchSupportMCJIT() functions in unittests/ExecutionEngine/MCJIT/MCJITTestBase.h uses "Host Triple" to check for compatibility. Since we cross-compile on X86, "Host Triple" for us will be "X86" which is a supported architecture. I tried removing it from the supported arch list but didn't see any effect. I was just wondering if these tests are

...> Yes, that is one of the intended use models for MCJIT. > > > > If you look at the source for ‘lli’ you’ll find an option called > “remote-mcjit” which does exactly this (for testing purposes). > > > > The key function (which in the lli case is called from lli’s > RemoteMemoryManager::notifyObjectLoaded method) is > ExecutionEngine::mapSectionAddress. This function tells MCJIT to reapply > relocations to the loaded object as if it were loaded at a different > address in memory than it actually is. The client is responsible for the > particulars of allocating mem...

...e target triple as well... This was just a temporary change to see how it works. >There isn't anything in MCJIT as far as I know that prevents cross compilation. >That said, the SectionMemoryManager that's used by the unit tests doesn't >support remote execution. However, the RemoteMemoryManager has been >improving lately; it could foreseeably be used to add remote execution >support to the tests. That explains why MCJIT test executable (build/unittests/ExecutionEngine/MCJIT/MCJITTests) was an X86 binary in my case. It appears to me that these tests will always fail for cross-comp...

...> Yes, that is one of the intended use models for MCJIT. > > > > If you look at the source for ‘lli’ you’ll find an option called > “remote-mcjit” which does exactly this (for testing purposes). > > > > The key function (which in the lli case is called from lli’s > RemoteMemoryManager::notifyObjectLoaded method) is > ExecutionEngine::mapSectionAddress. This function tells MCJIT to reapply > relocations to the loaded object as if it were loaded at a different > address in memory than it actually is. The client is responsible for the > particulars of allocating mem...

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Mikhail Lyapunov > Subject: [LLVMdev] Multiple modules JITting > We're looking for a way to use LLVM to JIT many modules, assuming that > the full list of modules and their content are not available at a time > when some of jitted pieces are already in use. We do this in our

Hi, Can you please clarify? We're looking for a way to use LLVM to JIT many modules, assuming that the full list of modules and their content are not available at a time when some of jitted pieces are already in use. Is it feasible to destruct ExecutionEngine but keep jitted code alive? Are jitted binary codes position independent? (or is there a way to relocate) If the solution requires

...ng OrcLazyJIT.cpp for Release+Asserts build llvm[2]: Linking Release+Asserts executable llvm-extract (without symbols) llvm[2]: ======= Finished Linking Release+Asserts Executable opt (without symbols) make[2]: Leaving directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/tools/opt' llvm[2]: Compiling RemoteMemoryManager.cpp for Release+Asserts build make[2]: Entering directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/tools/llvm-mc' llvm[2]: ======= Finished Linking Release+Asserts Executable llvm-extract (without symbols) make[2]: Leaving directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/tools/llvm-extract' llv...