similar to: [LLVMdev] FP Constants spilling to memory in x86 code generation

On Mon, 6 Dec 2004, Morten Ofstad wrote: > Hello, > > I've tracked down a new memory leak which started happening when I enabled > constant propagation (I created my own passmanager which I run before calling > getPointerToGlobal to JIT the function I have generated - is this OK?). Yes, that's perfectly ok! The interface to do this could probably be improved, but I

Chris Lattner wrote: > On Mon, 6 Dec 2004, Morten Ofstad wrote: >> I guess what I'd like to know is if the process of spilling constants >> to memory could be a bit more controlled, maybe using the JIT memory >> manager and putting it in with the function stubs? > > Yes, this can and should definitely be improved. If you look at >

On Mon, 13 Dec 2004, Morten Ofstad wrote: > I have made a patch along these lines. Although I reused the JITMemoryManager > object, I am allocating constant pools from another block of memory. This > fixes my remaining leaks. It would be nice if also the global variables were > allocated in this way, but it's not needed for my application since I'm > managing that memory

Chris Lattner wrote: > On Mon, 13 Dec 2004, Morten Ofstad wrote: > >> I have made a patch along these lines. Although I reused the >> JITMemoryManager object, I am allocating constant pools from another >> block of memory. This fixes my remaining leaks. It would be nice if >> also the global variables were allocated in this way, but it's not >> needed

Hi everyone, vmkit requires to know the size of a jitted method before emitting the method. This allows to allocate the correct size for the method. The attached patch creates this functionality when the flag SizedMemoryCode is on. In order to implement this functionality, i had to virtualize some MachineCodeEmitter functions. Is it OK to commit the patch? Thanks, Nicolas --------------

Hi Evan, Evan Cheng wrote: > 1) How are you computing size of the method being > jitted? I add a new pass with addSimpleCodeEmitter, with the emitter being a SizeEmitter. Since the target calls the emitter with functions such as writeByte, writeWord, etc.... the SizeEmitter class implements these function by incrementing a counter. At the end of the pass, the code size of the

Evan Cheng wrote: > On Apr 1, 2008, at 12:50 AM, Nicolas Geoffray wrote: > > > That's a hack. :-) It is if you think that code emitter should only be used for actually writing somewhere the data. It is not if you find it another useful utility ;-) > Some targets already have ways to compute the exact > size of a function. See ARM::GetFunctionSize()

Evan Cheng wrote: > > Let's see. ARM has it already. PPC has getNumBytesForInstruction so > you only need to add one to compute function size. Also you only need > to implement it for targets that support JIT right now, which leaves > Alpha and X86. I'm guessing Alpha is using fixed encoding so it should > be pretty easy. Or you can just punt it and let the target

Hi, Two questions. 1) How are you computing size of the method being jitted? 2) Why not simply add the functionality of allocating emission buffer of specific size to MachineCodeEmitter instead? Thanks, Evan On Mar 30, 2008, at 12:05 PM, Nicolas Geoffray wrote: > Hi everyone, > > vmkit requires to know the size of a jitted method before emitting > the method. This allows to

On Apr 1, 2008, at 12:50 AM, Nicolas Geoffray wrote: > Hi Evan, > > Evan Cheng wrote: >> 1) How are you computing size of the method being >> jitted? > > I add a new pass with addSimpleCodeEmitter, with the emitter being a > SizeEmitter. Since the target calls the emitter with functions such as > writeByte, writeWord, etc.... the SizeEmitter class implements these

On Apr 4, 2008, at 11:16 PM, Nicolas Geoffray <nicolas.geoffray at lip6.fr> wrote: > Evan Cheng wrote: >> >> Let's see. ARM has it already. PPC has getNumBytesForInstruction so >> you only need to add one to compute function size. Also you only need >> to implement it for targets that support JIT right now, which leaves >> Alpha and X86. I'm

On Apr 4, 2008, at 5:50 AM, Nicolas Geoffray wrote: > Evan Cheng wrote: >> On Apr 1, 2008, at 12:50 AM, Nicolas Geoffray wrote: >> >> >> That's a hack. :-) > > It is if you think that code emitter should only be used for actually > writing somewhere the data. It is not if you find it another useful > utility ;-) Except it's pretty slow at it. :-)

Hi Evan, Evan Cheng wrote: > > I don't think the duplication is going to be top much of a problem. If > it is, I'll bug you about refactoring. :) > > I don't mean to show how lazy I can be, but I also need to know the size of the exception table emitted in memory (JITDwarfEmitter.cpp). Reviewing it a little, I can not see how things won't be duplicated.

> 6. When ExecutionEngine::create was called with parameter > "GVsWithCode" set to its default value of true, I got a segfault when > trying to get a pointer to one of my globals.  JIT::getMemoryForGV was > returning NULL in that case.  Explicitly passing false for > "GVsWithCode" cleared it up. That's no good. Could you send me a stack trace and explain

Dear all, Here's a new patch with Evan's comments (thx Evan!) and some cleanups. Now the (duplicated) exception handling code is in a new file: lib/ExecutionEngine/JIT/JITDwarfEmitter. This patch should work on linux/x86 and linux/ppc (tested). Nicolas -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jit-exceptions.patch URL:

Hi everyone, Here's a patch that enables exception handling when jitting. I've copy/pasted _many_code from lib/Codegen/DwarfWriter.cpp, so we may need to factorize it, but the functionality is there and I'm very happy with it :) lli should now be able to execute the output from llvm-gcc when using exceptions (the UnwindInst instruction is not involved in this patch). Just add the

Is there any way to get llvm to not spill floating point constants to memory but to keep them in registers, i.e. get rid of the constantPool and just generate ConstantFP instructions? Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054 P: 408-572-6219 F: 408-572-6596 -------------- next part

On Tue, Oct 7, 2008 at 4:02 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > Is there any way to get llvm to not spill floating point constants to memory > but to keep them in registers, i.e. get rid of the constantPool and just > generate ConstantFP instructions? "setOperationAction(ISD::ConstantFP, MVT::f32, Legal);"? -Eli

Hi Quentin, Sorry for the delay, I've been bogged down with other things today. On 14 July 2015 at 18:48, Quentin Colombet <qcolombet at apple.com> wrote: >> >> * A rematerializable interval once split is no longer rematerializable * >> >> The isRematerializable check in CalcSpillWeights.cpp uses the target >> instruction info to check that the machine

Looks sane. Thanks. Evan On Feb 1, 2008, at 1:24 AM, Nicolas Geoffray wrote: > Dear all, > > Here's a new patch with Evan's comments (thx Evan!) and some cleanups. > Now the (duplicated) exception handling code is in a new file: > lib/ExecutionEngine/JIT/JITDwarfEmitter. > > This patch should work on linux/x86 and linux/ppc (tested). > > Nicolas > Index: