search for: bussink

...e 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

...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...

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: Re: [LLVMdev] Memory clean for applications using LLVM for JIT compilation Hi Andy, One of the issues that I found not intuitive, is that when an ExecutionEngine is deallocated,...

...nce 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_FILE&qu...

...opy 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 >> d...

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 for our...

...ne, 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 function and c...

...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

...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...

...magine why the user should be forced to serialize creation of MCContext objects. I would suggest filing a bug for this. A simple lock probably wouldn't be too detrimental to performance here, since MCContext objects shouldn't be created too often. 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_FILE&qu...

...mitations aren't a concern for you, I suggest you give MCJIT a try. It has some nice benefits and is being more actively maintained. -Andy -----Original Message----- From: Frank Henigman [mailto:fjhenigman at google.com] Sent: Wednesday, March 20, 2013 9:14 AM To: Kaylor, Andrew Cc: Dirkjan Bussink; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Memory clean for applications using LLVM for JIT compilation It seems wrong to delegate a dozen or more methods when I only want to change the behavior in a couple small ways. It would have been easier to derive a class, but the base class is inacces...

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 > 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

...iew a custom mgr should be owned by the client code but that is not how it works right now. You probably have to copy out the JIT code into your own block of memory. ________________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] on behalf of Dirkjan Bussink [d.bussink at gmail.com] Sent: Sunday, January 20, 2013 6:54 AM To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Memory clean for applications using LLVM for JIT compilation On 14 Jan 2013, at 15:48, Reid Kleckner <rnk at google.com> wrote: > > Or maybe would it be possible to have a...

> 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 understand the...

> On 14 Jan 2013, at 15:48, Reid Kleckner <rnk at google.com> wrote: > > > > Or maybe would it be possible to have a custom allocator for memory space for the native code 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. > > > > Yes, you should be

On 14 Jan 2013, at 15:48, Reid Kleckner <rnk at google.com> wrote: > > Or maybe would it be possible to have a custom allocator for memory space for the native code 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. > > Yes, you should be able to inherit from

Hi all, I'd like to ask about something I've been thinking about and haven't found a way to make this possible with LLVM, so I'm wondering whether I'm not looking properly or that indeed that can't be done currently. What I'm trying to do is to be able to modify generated assembly code after it has been created through LLVM. At this point the original LLVM IR

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 example of how to enable it). We're hoping to get rid of the old one soon, but there

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.

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