Displaying 6 results from an estimated 6 matches for "getjitinfo".
2008 Jun 16
0
[LLVMdev] PowerPC instruction cache invalidation
On Mon, 16 Jun 2008, Gary Benson wrote:
> When you genetate code on PowerPC you need to explicitly invalidate
> the instruction cache to force the processor to reread it. In LLVM
> there is code to do this for function stubs on Macintosh, but not
> for other platforms and not for JITted code generally.
Applied, thanks!
2008 Jun 17
1
[LLVMdev] PowerPC instruction cache invalidation
...what the problem is?
The attached patch generalizes it (aKor helped me out). I don't know
if Intel needs some kind of cache invalidation too but if it does it
could use the same hooks.
Cheers,
Gary
--
http://gbenson.net/
-------------- next part --------------
Index: include/llvm/Target/TargetJITInfo.h
===================================================================
--- include/llvm/Target/TargetJITInfo.h (revision 52391)
+++ include/llvm/Target/TargetJITInfo.h (working copy)
@@ -94,6 +94,11 @@
assert(NumRelocs == 0 && "This target does not have relocations!");...
2004 Oct 18
3
[LLVMdev] Fix for non-standard variable length array + Visual C X86 specific code
Paolo Invernizzi wrote:
> There was a similar problem some time ago, and was resolved with alloca.
> I think it's a better solution to use the stack instead of the heap...
I tend to agree, but the constructors won't get called if it's an object
array -- anyway, this particular case there was no objects, just
pointers and bools so alloca should be fine. I'll leave it to
2008 Jun 16
6
[LLVMdev] PowerPC instruction cache invalidation
Hi all,
When you genetate code on PowerPC you need to explicitly invalidate
the instruction cache to force the processor to reread it. In LLVM
there is code to do this for function stubs on Macintosh, but not
for other platforms and not for JITted code generally.
The attached patch adds support for GNU platforms, but I can't figure
out a nice way to call it for all generated code. Can
2008 Apr 16
0
[LLVMdev] Being able to know the jitted code-size before emitting
...ction.
> MCE.emitByte(BaseOpcode);
> - emitConstant(0, sizeOfImm(Desc));
> + emitConstant(0, X86InstrInfo::sizeOfImm(Desc));
> // Remember PIC base.
> PICBaseOffset = MCE.getCurrentPCOffset();
> X86JITInfo *JTI = dynamic_cast<X86JITInfo*>(TM.getJITInfo());
> @@ -657,7 +522,7 @@
> } else if (MO.isExternalSymbol()) {
> emitExternalSymbolAddress(MO.getSymbolName(),
> X86::reloc_pcrel_word);
> } else if (MO.isImmediate()) {
> - emitConstant(MO.getImm(), sizeOfImm(Desc));
> + emitConstant(MO.get...
2008 Apr 15
4
[LLVMdev] Being able to know the jitted code-size before emitting
OK, here's a new patch that adds the infrastructure and the
implementation for X86, ARM and PPC of GetInstSize and GetFunctionSize.
Both functions are virtual functions defined in TargetInstrInfo.h.
For X86, I moved some commodity functions from X86CodeEmitter to
X86InstrInfo.
What do you think?
Nicolas
Evan Cheng wrote:
>
> I think both of these belong to TargetInstrInfo. And