search for: dirkjan

...ubinius/blob/master/vm/llvm/jit_memory_manager.hpp https://github.com/rubinius/rubinius/blob/master/vm/llvm/jit_memory_manager.cpp If there are better ways to clean up the code, that would be great, but having to things like that is what made me state feeling dirty on how it was implemented. -- Dirkjan On Mar 19, 2013, at 01:56 , "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote: > I'm not sure I see why the delegating memory manager feels wrong to both of you. That's exactly the kind of usage model I would envision for clients that needed to handle multiple Execu...

Hi Dirkjan, Are you using JIT or MCJIT? Cheers. ________________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] on behalf of Dirkjan Bussink [d.bussink at gmail.com] Sent: Saturday, March 23, 2013 8:18 AM To: Kaylor, Andrew Cc: llvmdev at cs.uiuc.edu Subject:...

...t seems like I'll still be allowed to have the types in there for backwards compatibility, but I wonder if it wouldn't be worthwhile to also keep some of the type-checking in the verification code, and only ditch all the type information (or, just not consider it) after that part. Cheers, Dirkjan

Hello all, When using the JIT on ARM, I get the following error message. The code works fine on both X86 32 and 64 bit architectures. rbx: /home/dirkjan/llvm-3.3.src/include/llvm/CodeGen/MachineOperand.h:260: unsigned int llvm::MachineOperand::getReg() const: Assertion `isReg() && "This is not a register operand!"' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 0x74fff460 (LWP 652)] __libc_do_syscall (...

...use my copy of the code. However when I call setRelocationModel(Reloc::PIC_) on the engine builder I get code that seg faults. The assembly looks plausible at a glance, but I'm not really up to speed on x86 assembly. Is PIC supposed to work with JIT on X86-32? On Sat, Mar 16, 2013 at 11:35 AM, Dirkjan Bussink <d.bussink at gmail.com> wrote: > > On Mar 7, 2013, at 20:48 , Frank Henigman <fjhenigman at google.com> wrote: > >> I derived a class from JITMemoryManager which delegates everything to >> an instance made with CreateDefaultMemManager(). ExecutionEngine &g...

On Tue, Feb 17, 2015 at 8:56 AM, Antoine Pitrou <antoine at python.org> wrote: > > Hi, > > Dirkjan Ochtman <dirkjan <at> ochtman.nl> writes: > > > > As far as I understand, this change is wanted because the LLVM > > infrastructure derives no value from knowing the types, and there's a > > cost in terms of code spent to support all of it. I've been crea...

...rding the thread safety, this is what the open group says about getenv(): "The getenv() function need not be reentrant. A function that is not required to be reentrant is not required to be thread-safe." http://pubs.opengroup.org/onlinepubs/009696799/functions/getenv.html -- Regards, Dirkjan Bussink

...JIT engine, and if you're interested in using it I'd be happy to talk to you about future design directions. -Andy -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Frank Henigman Sent: Sunday, March 17, 2013 2:18 PM To: Dirkjan Bussink Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Memory clean for applications using LLVM for JIT compilation Thanks for the reply, nice to have some validation. I thought of another approach which might be preferable: generate relocatable code, use a JITEventListener to grab each functi...

...sing stance is that you setenv/putenv are not thread safe, but getenv is. I assume Ruby exposes setenv and therefore simply not calling setenv isn't an option. Would it solve your problems if all getenv() calls happened at cl::ParseCommandLineOptions() time? On Thu, May 23, 2013 at 9:49 AM, Dirkjan Bussink <d.bussink at gmail.com>wrote: > Hello, > > In Rubinius we're seeing an occasional crash inside LLVM that always > happens inside getenv(), which is used for example when creating a > MCContext (inside lib/MC/MCContext.cpp, it checks > getenv("AS_SECURE_LOG...

... and that's kind of annoying when I'm trying to debug something. Also, it doesn't seem like openssh.org lists the IRC channel (even though it's referenced) anywhere. Cheers, Dirkjan

Hi Dirkjan, > I've tried looking for this error, but can't seem to find any more information on what the cause of this could be. This looks like a backtrace from the legacy JIT. Unfortunately that's known to be broken on ARM and you should use the MCJIT instead (see tools/lli/lli.cpp for an e...

...> fortunate that I discovered the Windows release in v3.1 and quickly grabbed > it and tried it out.  And it seems to run very well so far. The best thing you can probably do is setup a buildbot slave, so that developers will actually become aware when their changes break Windows. Cheers, Dirkjan

On Mon, Jan 14, 2013 at 4:56 AM, Dirkjan Bussink <d.bussink at gmail.com>wrote: > Hello all, > > I've already bothered people on IRC with this question and it was > recommended to ask it here. > > First of all, some context. In Rubinius (http://rubini.us/, > http://github.com/rubinius/rubinius) we use LLVM...

...s to Bayonne through H323. Anyone care to share his views on this approach? Any pointers or do's and don'ts? All info is greatly appreciated! Regards, Dirk-Jan -- Dirk-Jan Wemmers, Capcave B.V. Zonnebaan 17, 3542EA Utrecht T +31(0)30-2149670, F +31(0)30-2149679 M +31(0)651 063040, E dirkjan@capcave.com

...in using it I'd be happy to talk to you about future design directions. > > -Andy > > > > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Frank Henigman > Sent: Sunday, March 17, 2013 2:18 PM > To: Dirkjan Bussink > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Memory clean for applications using LLVM for JIT compilation > > Thanks for the reply, nice to have some validation. I thought of another approach which might be preferable: > generate relocatable code, use a JITEventList...

...now on x86_64 this is tricky, because it retrieves the function to call from a register and isn't encoded directly in the call instruction (like on x86). So are there any ways to tackle this issue using certain mechanisms in LLVM? Hopefully someone is able to help out with this problem. -- Dirkjan

...o create a bug report. Looking at the code of > LLParser::ParseGetElementPtr, the error handling appears to be very > simplistic, so I don't think there's any fundamental reason for not > doing a better job there. Filed http://llvm.org/bugs/show_bug.cgi?id=14965, thanks! Cheers, Dirkjan

...ultMemManager(). ExecutionEngine > destroys the wrapper, but I keep the inner instance which did the > actual work. Works, but seems a bit ugly. Did you find any other > solutions? I ended up implementing the exact same thing, it feels dirty but it has worked great for us so far. -- Dirkjan

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Dirkjan Bussink > Subject: [LLVMdev] Modifying machine code after it's generated with LLVM > I'd need to be able to pass a memory address where the actual native > code is generated to this fallback function, but I haven't found any > ways of doing this. Perhaps I don't unders...

...that we could provide? With this last option we would be responsible for the clean up ourselves and just provide memory space to LLVM where it can store the results. We're open to different approaches, but we would like to know the recommendations from the LLVM community here. -- Regards, Dirkjan Bussink