search for: emitconstantpool

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

...#include "llvm/Target/TargetJITInfo.h" >> @@ -370,6 +376,7 @@ >> virtual void startFunction(MachineFunction &F); >> virtual bool finishFunction(MachineFunction &F); >> >> + void initConstantPool(MachineConstantPool *MCP); >> void emitConstantPool(MachineConstantPool *MCP); >> void initJumpTableInfo(MachineJumpTableInfo *MJTI); >> void emitJumpTableInfo(MachineJumpTableInfo *MJTI); >> @@ -469,19 +476,47 @@ >> >> >> void JITEmitter::startFunction(MachineFunction &F) { >> - uintptr_t Actua...

.../TargetData.h" > #include "llvm/Target/TargetJITInfo.h" > @@ -370,6 +376,7 @@ > virtual void startFunction(MachineFunction &F); > virtual bool finishFunction(MachineFunction &F); > > + void initConstantPool(MachineConstantPool *MCP); > void emitConstantPool(MachineConstantPool *MCP); > void initJumpTableInfo(MachineJumpTableInfo *MJTI); > void emitJumpTableInfo(MachineJumpTableInfo *MJTI); > @@ -469,19 +476,47 @@ > > > void JITEmitter::startFunction(MachineFunction &F) { > - uintptr_t ActualSize; > - BufferBegin =...

...Target/TargetJITInfo.h" >>> @@ -370,6 +376,7 @@ >>> virtual void startFunction(MachineFunction &F); >>> virtual bool finishFunction(MachineFunction &F); >>> >>> + void initConstantPool(MachineConstantPool *MCP); >>> void emitConstantPool(MachineConstantPool *MCP); >>> void initJumpTableInfo(MachineJumpTableInfo *MJTI); >>> void emitJumpTableInfo(MachineJumpTableInfo *MJTI); >>> @@ -469,19 +476,47 @@ >>> >>> >>> void JITEmitter::startFunction(MachineFunction &F) { >&...

...uot; >>>> @@ -370,6 +376,7 @@ >>>> virtual void startFunction(MachineFunction &F); >>>> virtual bool finishFunction(MachineFunction &F); >>>> >>>> + void initConstantPool(MachineConstantPool *MCP); >>>> void emitConstantPool(MachineConstantPool *MCP); >>>> void initJumpTableInfo(MachineJumpTableInfo *MJTI); >>>> void emitJumpTableInfo(MachineJumpTableInfo *MJTI); >>>> @@ -469,19 +476,47 @@ >>>> >>>> >>>> void JITEmitter::startFunction(Machine...

...7 @@ >>>>>> virtual void startFunction(MachineFunction &F); >>>>>> virtual bool finishFunction(MachineFunction &F); >>>>>> >>>>>> + void initConstantPool(MachineConstantPool *MCP); >>>>>> void emitConstantPool(MachineConstantPool *MCP); >>>>>> void initJumpTableInfo(MachineJumpTableInfo *MJTI); >>>>>> void emitJumpTableInfo(MachineJumpTableInfo *MJTI); >>>>>> @@ -469,19 +476,47 @@ >>>>>> >>>>>> >>>>&...

...>>>> virtual void startFunction(MachineFunction &F); >>>>>>> virtual bool finishFunction(MachineFunction &F); >>>>>>> >>>>>>> + void initConstantPool(MachineConstantPool *MCP); >>>>>>> void emitConstantPool(MachineConstantPool *MCP); >>>>>>> void initJumpTableInfo(MachineJumpTableInfo *MJTI); >>>>>>> void emitJumpTableInfo(MachineJumpTableInfo *MJTI); >>>>>>> @@ -469,19 +476,47 @@ >>>>>>> >>>>>>>...

...> @@ -370,6 +376,7 @@ >>>>> virtual void startFunction(MachineFunction &F); >>>>> virtual bool finishFunction(MachineFunction &F); >>>>> >>>>> + void initConstantPool(MachineConstantPool *MCP); >>>>> void emitConstantPool(MachineConstantPool *MCP); >>>>> void initJumpTableInfo(MachineJumpTableInfo *MJTI); >>>>> void emitJumpTableInfo(MachineJumpTableInfo *MJTI); >>>>> @@ -469,19 +476,47 @@ >>>>> >>>>> >>>>> void JITEmitter:...

...virtual void startFunction(MachineFunction &F); >>>>>>>> virtual bool finishFunction(MachineFunction &F); >>>>>>>> >>>>>>>> + void initConstantPool(MachineConstantPool *MCP); >>>>>>>> void emitConstantPool(MachineConstantPool *MCP); >>>>>>>> void initJumpTableInfo(MachineJumpTableInfo *MJTI); >>>>>>>> void emitJumpTableInfo(MachineJumpTableInfo *MJTI); >>>>>>>> @@ -469,19 +476,47 @@ >>>>>>>> >>>...

...startFunction(MachineFunction &F); >>>>>>>>> virtual bool finishFunction(MachineFunction &F); >>>>>>>>> >>>>>>>>> + void initConstantPool(MachineConstantPool *MCP); >>>>>>>>> void emitConstantPool(MachineConstantPool *MCP); >>>>>>>>> void initJumpTableInfo(MachineJumpTableInfo *MJTI); >>>>>>>>> void emitJumpTableInfo(MachineJumpTableInfo *MJTI); >>>>>>>>> @@ -469,19 +476,47 @@ >>>>>>>>&gt...

Hi again, Actually, I've just been looking at the existing code and the ARM solution may be over-complicated for this situation. You should be able to override EmitConstantPool directly, or possibly even just override getSectionForConstantKind in X86LinuxTargetObjectFile (and perhaps others) to return .text. Tim.

...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 ExecutionEngine/JIT/JITEmitter.cpp:emitConstantPool, you can see that the JIT is just new'ing a block of memory for every constant pool that is needed. This is, admittedly, antisocial for your application, so if you'd like to make a memory manager for it, feel free. > If not, I have to add tracking to the allocations here so they can...

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?). The reason is that FP constants are being spilled to memory as there is no immediate fp load available. In my case this is a bit unnecessary since the

Hi, I'd like to generate constants inside .text in order to use ip-relative loads, when the code model is "large". How can I do this? (I'm on X86_64 linux) Thank you. - Elena --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the

Hi Elena, > I’d like to generate constants inside .text in order to use ip-relative > loads, when the code model is “large”. I don't think this is a sequence the x86 backend supports at the moment, but it is how ARM handles its constant-pools. The outline is that you have a pass which looks through a functions constpool uses and emits a pseudo-instruction for each, which is then

...om] Sent: Tuesday, June 25, 2013 15:08 To: Demikhovsky, Elena Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Contants generation Hi again, Actually, I've just been looking at the existing code and the ARM solution may be over-complicated for this situation. You should be able to override EmitConstantPool directly, or possibly even just override getSectionForConstantKind in X86LinuxTargetObjectFile (and perhaps others) to return .text. Tim. --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential materi...

...om] Sent: Tuesday, June 25, 2013 15:08 To: Demikhovsky, Elena Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Contants generation Hi again, Actually, I've just been looking at the existing code and the ARM solution may be over-complicated for this situation. You should be able to override EmitConstantPool directly, or possibly even just override getSectionForConstantKind in X86LinuxTargetObjectFile (and perhaps others) to return .text. Tim. --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential materi...

...ow 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 > ExecutionEngine/JIT/JITEmitter.cpp:emitConstantPool, you can see that > the JIT is just new'ing a block of memory for every constant pool that > is needed. This is, admittedly, antisocial for your application, so if > you'd like to make a memory manager for it, feel free. > > I think that adding something like the JITMemo...