similar to: [LLVMdev] MCJIT RemoteMemoryManager Failures on ARM

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

I'd be OK with disabled these tests if they can be specifically disabled for ARM with clang. The main purpose of these tests is to ensure that none of the MCJIT/RuntimeDyld/*MemoryManager layering gets rearranged in a way that makes remote execution impossible. I would also note that the failure isn't actually in anything MCJIT-specific. Aside from the fact that it seems to be

Looking at the code, one obvious source of intermittent failure is that the Linux implementations of ReadBytes and WriteBytes don't check for EINTR. I doubt that's the failure you're seeing because it would be more randomly distributed but it's something that should be fixed. More likely as the cause of failure in your case is that read is returning less than the number of bytes

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,

> + /// allocateSpace - reserves space in the current block if any, or > + /// allocate a new one of the given size + virtual void > *allocateSpace(intptr_t Size, unsigned Alignment); + > Please capitalize "reserves". ok. > + /// allocateSpace - general-purpose space allocator > Better comments please. :-) Also please end the sentence with a period > or Chris'

Thanks Nuno and Dale. Some comments: + /// allocateSpace - reserves space in the current block if any, or + /// allocate a new one of the given size + virtual void *allocateSpace(intptr_t Size, unsigned Alignment); + Please capitalize "reserves". + /// allocateSpace - general-purpose space allocator Better comments please. :-) Also please end the sentence with a period or Chris'

On Oct 16, 2008, at 11:29 AM, Nuno Lopes wrote: >> + /// allocateSpace - reserves space in the current block if any, or >> + /// allocate a new one of the given size + virtual void >> *allocateSpace(intptr_t Size, unsigned Alignment); + >> Please capitalize "reserves". > > ok. > > >> + /// allocateSpace - general-purpose space allocator >>

Mesa (http://www.mesa3d.org/) uses LLVM to compile shaders. These are typically small bits of code (~10KB) and one application can use many of them. Mesa creates an ExecutionEngine with a default JIT memory manager for each shader it compiles, and keeps the engine around as long as the shader code is needed. This results in memory waste of ~1MB for each shader. Half the overhead is in the

Hi Frank, The project really needs to be looking to move away from the old JIT and to MCJIT. LLVM is actively working to kill the old JIT. It’s already unmaintained. MCJIT is the way forward. Can you elaborate on what’s blocking its adoption for Mesa? -Jim On Oct 1, 2013, at 10:44 AM, Frank Henigman <fjhenigman at google.com> wrote: > Mesa (http://www.mesa3d.org/) uses LLVM to compile

I'll try to find out, or get someone to explain, why Mesa selects MCJIT with LLVM 3.1 only and JIT for other LLVM versions. I'm not keen to code a fourth attempt (1: copy JIT code, 2: delegating manger, 3: derive from DefaultJITMemoryManager, 4: copy MCJIT code) but I'll try copying code with MCJIT. Is that the usual route for people who want to delete all LLVM engines, etc. while

>> Ok, thanks for the explanation. So my first patch doesn't work. >> Also, to be >> clear, this bug has nothing to do with overflowing the JIT memory >> buffer. >> I made another one that takes keeps the allocation of global >> variables in >> the JIT buffer, but it creates a new mem block if it doesn't exist >> (i.e. >> when dumping a

Remote mcjit has never worked on arm. By removing the assertion, we're no longer seeing deterministic failures. I think by fixing PR16013 we'll enable support for remote mcjit on arm, and can then remove the xfails altogether. In the meantime, marking the tests as unsupported seems to be the best option. I don't have a machine for a few days but I can take a look at finally cleaning

On OS X (10.6.2) running on an Intel Core 2 duo with LLVM 2.7 pulled about a month ago from CVS and built in debug mode: Using the JIT system with exception handling, I am having issues with type infos. "Finally" code (llvm.eh.selector intrinsic call with 0) works fine (correct landing pads found), as does this call with one type info. My type infos are each 64 bit array GlobalVariables

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

Aha. Thanks. Seems like I need to call mapSectionAddress with the target address. But how I copy the code? What function would I call? On Wed, Mar 25, 2015 at 4:32 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > 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

> Both A9 bots are running the same Ubuntu (13.03), with the same GCC (4.7.2), > and are the same hardware (Panda ES RevB), so it really strikes me as odd > that we have such a different behaviour between them. Hmm. I'll see what I can do on my tablet (not tried building LLVM there before so it could take a while), it seems like there are *some* failures everywhere. If we're

Hi, The following code: #include<stdio.h> char bigArray[0x1000000]; int main(int argc, char **argv) { printf("mem: 0x%x\n", (unsigned) bigArray); return 0; } causes lli to silently fail, even though it compiles correctly with llc. The reason is that in JITEmitter.cpp only checks to see if CurBufferPtr == BufferEnd at the beginning of the function and not after all

No, I was asking how to extract the code from MCJIT, and you said it use a custom memory manager. When you say that I must treat each section as a block, do you mean that there is inter-block relative offsets need to be maintained? Or that when I get a section, I must copy it to target process memory as a one-shot contiguous block. If it's second, I think we're ok. On Wed, Mar 25, 2015

Here is the corrected version. Thomas Jablin wrote: > Actually, there is a problem with the patch. Please delay review. > > Thomas Jablin wrote: > >> Hi, >> The following code: >> >> #include<stdio.h> >> >> char bigArray[0x1000000]; >> >> int main(int argc, char **argv) { >> printf("mem: 0x%x\n", (unsigned)