Displaying 20 results from an estimated 5000 matches similar to: "[LLVMdev] Usage of getenv() inside LLVM and thread safety"
2013 May 23
0
[LLVMdev] Usage of getenv() inside LLVM and thread safety
Right. glibc's amusing 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,
>
>
2013 May 23
0
[LLVMdev] Usage of getenv() inside LLVM and thread safety
That sounds like a missed multi-threading issue with LLVM. I can't imagine
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
2013 Mar 23
2
[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, the memory manager's destructor is also called. This resulted in having to write two objects in my case, one as a per JIT request memory manager and one global JIT memory manager.
The per request JIT memory manager gets memory from the global manager, but both ended up implementing
2013 May 23
2
[LLVMdev] Usage of getenv() inside LLVM and thread safety
On Thu, May 23, 2013 at 8:13 AM, Justin Holewinski <
justin.holewinski at gmail.com> wrote:
> That sounds like a missed multi-threading issue with LLVM. I can't
> imagine 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
2013 Mar 23
0
[LLVMdev] Memory clean for applications using LLVM for JIT compilation
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
2013 Jan 14
3
[LLVMdev] Memory clean for applications using LLVM for JIT compilation
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 JIT. We create LLVM IR using the C++ API and turn that into machine code using ExecutionEngine::runJITOnFunction. The resulting native code is then installed as the
2013 Jan 14
0
[LLVMdev] Memory clean for applications using LLVM for JIT compilation
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 JIT. We create
> LLVM IR using the C++ API and
2013 Mar 17
3
[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 copy it to my own memory,
let all the LLVM stuff die normally then 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
2013 Mar 19
0
[LLVMdev] Memory clean for applications using LLVM for JIT compilation
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 ExecutionEngines that had reason to share a memory manager. I'm saying this as an invitation to discussion, not to be argumentative. We certainly could change things if it would make the design better.
2013 Apr 12
2
[LLVMdev] Modifying machine code after it's generated with LLVM
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
2013 Oct 01
5
[LLVMdev] JIT compiler on ARM issue
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.
2013 Mar 20
2
[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 inaccessible (in an anonymous
namespace). And I was afraid to roll my own memory manager because I
didn't understand what all those methods do.
So MCJIT is future - will JITMemoryManager remain relevant? If so I
2013 Mar 08
2
[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 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
2013 Mar 16
0
[LLVMdev] Memory clean for applications using LLVM for JIT compilation
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
2013 Jan 20
1
[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 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
2013 Apr 12
0
[LLVMdev] Modifying machine code after it's generated with LLVM
> 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
2013 Oct 01
0
[LLVMdev] JIT compiler on ARM issue
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
2008 Jun 01
3
rbx gem
Hello. Some time ago I committed a Rubinius assembly-based HTTP parser
generated from Ragel to the Rubinius git repository. Yesterday I made a
Mongrel gem which installs and works on Rubinius. This basically involved
commenting out anything to do with fastthread or the http11 C extension.
If there''s interest in releasing a Rubinius-targeted gem, I can make changes
to the Rakefile to
2010 Jun 17
3
unicorn 1.0.0 - yes, this is a real project
Unicorn is an HTTP server for Rack applications designed to only serve
fast clients on low-latency, high-bandwidth connections and take
advantage of features in Unix/Unix-like kernels. Slow clients should
only be served by placing a reverse proxy capable of fully buffering
both the the request and response in between Unicorn and slow clients.
* http://unicorn.bogomips.org/
* mongrel-unicorn at
2011 Aug 29
0
[LLVMdev] PTX target for LLVM!
Hi everyone,
I downloaded the latest version of LLVM PTX backend from
http://www.prog.uni-saarland.de/projects/anysl
and made the required changes to all the files mentioned in the README. But
I get the following error when I compile it.
llvm[3]: Compiling PTXBackend.cpp for Release build
In file included from PTXBackend.h:70:0,
from PTXBackend.cpp:36:
PTXPasses.h: In constructor