| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
emitted or the machine code for a function is freed. Chris mentioned that we
may also want a notification when a stub is emitted, but that'll be a future
change. I intend to use this to tell oprofile where functions are emitted and
what lines correspond to what addresses.
llvm-svn: 74157
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
integer and floating-point opcodes, introducing
FAdd, FSub, and FMul.
For now, the AsmParser, BitcodeReader, and IRBuilder all preserve
backwards compatability, and the Core LLVM APIs preserve backwards
compatibility for IR producers. Most front-ends won't need to change
immediately.
This implements the first step of the plan outlined here:
http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt
llvm-svn: 72897
|
|
|
|
| |
llvm-svn: 72821
|
|
|
|
| |
llvm-svn: 72783
|
|
|
|
| |
llvm-svn: 72650
|
|
|
|
|
|
| |
JITCodeEmitter and ObjectCodeEmitter. No functional changes yet. Patch by Aaron Gray
llvm-svn: 72631
|
|
|
|
|
|
|
|
|
|
| |
code.
Introduce a new class (MachineCodeInfo) that the JIT can fill in with details. Right now, just the address and the size of the machine code are reported.
Patch by Evan Phoenix!
llvm-svn: 72040
|
|
|
|
|
|
|
| |
will make it more obvious what it represents, and stop
it being confused with the StoreSize.
llvm-svn: 71349
|
|
|
|
|
|
|
|
| |
function's machine code.
Don't include memory allocated for global variables during relocations resolution.
llvm-svn: 70517
|
|
|
|
|
|
|
|
|
|
|
|
| |
another stub, but then never calling the jitted function) can cause the JIT to
leave a stub in place. Judging by the comments this is a known deficiency, so
we're just not going to use AssertingVH for the StubToFunctionTy map.
Also shorten some lines longer than 80 columns.
This fixes the "make check" failure with ocaml on x86-64 linux.
llvm-svn: 70185
|
|
|
|
|
|
| |
freeMachineCodeForFunction was never called.
llvm-svn: 69531
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
unnecessary paddings between constant pool entries, larger than necessary alignments (e.g. 8 byte alignment for .literal4 sections), and potentially other issues.
1. ConstantPoolSDNode alignment field is log2 value of the alignment requirement. This is not consistent with other SDNode variants.
2. MachineConstantPool alignment field is also a log2 value.
3. However, some places are creating ConstantPoolSDNode with alignment value rather than log2 values. This creates entries with artificially large alignments, e.g. 256 for SSE vector values.
4. Constant pool entry offsets are computed when they are created. However, asm printer group them by sections. That means the offsets are no longer valid. However, asm printer uses them to determine size of padding between entries.
5. Asm printer uses expensive data structure multimap to track constant pool entries by sections.
6. Asm printer iterate over SmallPtrSet when it's emitting constant pool entries. This is non-deterministic.
Solutions:
1. ConstantPoolSDNode alignment field is changed to keep non-log2 value.
2. MachineConstantPool alignment field is also changed to keep non-log2 value.
3. Functions that create ConstantPool nodes are passing in non-log2 alignments.
4. MachineConstantPoolEntry no longer keeps an offset field. It's replaced with an alignment field. Offsets are not computed when constant pool entries are created. They are computed on the fly in asm printer and JIT.
5. Asm printer uses cheaper data structure to group constant pool entries.
6. Asm printer compute entry offsets after grouping is done.
7. Change JIT code to compute entry offsets on the fly.
llvm-svn: 66875
|
|
|
|
|
|
|
| |
variety. For example, an i64 div might turn into a call to __divdi3 during
legalization.
llvm-svn: 66646
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. When the JIT is asked to remove a function, updating it's
mapping to 0, we invalidate any function stubs used only
by that function. Now, also invalidate the JIT's mapping
from the GV the stub pointed to, to the address of the GV.
2. When dlsym stubs for cross-process JIT are enabled, do not
abort just because a named function cannot be found in the
JIT's process.
3. Fix various assumptions about when it is ok to use the lazy
resolver when non-lazy JITing is enabled.
llvm-svn: 66324
|
|
|
|
| |
llvm-svn: 66143
|
|
|
|
|
|
|
|
| |
This invalidates the stubs in the resolver map when they are no longer referenced,
and should the JIT memory manager ever pick up a deallocateStub interface, the
JIT could reclaim the memory for unused stubs as well.
llvm-svn: 66141
|
|
|
|
|
|
|
|
|
| |
on failure to resolve it.
Do not abort on failure to resolve an external symbol when using dlsym stubs,
since the symbol may not be in the JIT's address space. Just use 0.
Allow dlsym stubs to differentiate between GlobalVars and Functions.
llvm-svn: 66050
|
|
|
|
| |
llvm-svn: 65895
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that has not been JIT'd yet, the callee is put on a list of pending functions
to JIT. The call is directed through a stub, which is updated with the address
of the function after it has been JIT'd. A new interface for allocating and
updating empty stubs is provided.
Add support for removing the ModuleProvider the JIT was created with, which
would otherwise invalidate the JIT's PassManager, which is initialized with the
ModuleProvider's Module.
Add support under a new ExecutionEngine flag for emitting the infomration
necessary to update Function and GlobalVariable stubs after JITing them, by
recording the address of the stub and the name of the GlobalValue. This allows
code to be copied from one address space to another, where libraries may live
at different virtual addresses, and have the stubs updated with their new
correct target addresses.
llvm-svn: 64906
|
|
|
|
|
|
| |
suggested by Chris.
llvm-svn: 62099
|
|
|
|
|
|
|
|
| |
SingleSource/UnitTests/2007-04-25-weak.c in JIT mode. The test
now passes on systems which are able to produce a correct
reference output to compare with.
llvm-svn: 61674
|
|
|
|
|
|
| |
some overflow issues. Patch by Thomas Jablin.
llvm-svn: 60828
|
|
|
|
|
|
| |
actual function ptr instead of ptr to stub if function is already compiled.
llvm-svn: 60822
|
|
|
|
|
|
| |
is one). This makes it possible to compare function pointer values in lazy compilation mode. This fixes PR3043.
llvm-svn: 59265
|
|
|
|
| |
llvm-svn: 59119
|
|
|
|
| |
llvm-svn: 59007
|
|
|
|
| |
llvm-svn: 58952
|
|
|
|
| |
llvm-svn: 58898
|
|
|
|
|
|
| |
ptr.
llvm-svn: 58897
|
|
|
|
|
|
| |
these work on externsym machine relocations.
llvm-svn: 58895
|
|
|
|
| |
llvm-svn: 58894
|
|
|
|
| |
llvm-svn: 58868
|
|
|
|
| |
llvm-svn: 58835
|
|
|
|
| |
llvm-svn: 58807
|
|
|
|
| |
llvm-svn: 58788
|
|
|
|
| |
llvm-svn: 58782
|
|
|
|
| |
llvm-svn: 58778
|
|
|
|
|
|
| |
indirect gv reference. Please don't call it lazy.
llvm-svn: 58746
|
|
|
|
| |
llvm-svn: 58598
|
|
|
|
|
|
| |
doesn't want the generic constant pool to be emitted.
llvm-svn: 58475
|
|
|
|
| |
llvm-svn: 58407
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the ARM constant pool handling supercedes the standard LLVM constant
pool entirely, the JIT emitter does not allocate space for the constants,
nor initialize the memory. The constant pool is considered part of the
instruction stream.
Likewise, when resolving relocations into the constant pool, a hook into
the target back end is used to resolve from the constant ID# to the
address where the constant is stored.
For now, the support in the ARM emitter is limited to 32-bit integer. Future
patches will expand this to the full range of constants necessary.
llvm-svn: 58338
|
|
|
|
|
|
| |
JITing a variable independently of a function. This lead to sharing memory memory between functions and GVs thus changing the value of a GV could change the code in execution. more details on the ML.
llvm-svn: 57900
|
|
|
|
|
|
|
| |
this handling to work properly for modifying stub functions, relocations
back to entry points after JIT compilation, etc..
llvm-svn: 57013
|
|
|
|
|
|
| |
isReg, etc., from isRegister, etc.
llvm-svn: 57006
|
|
|
|
|
|
| |
the lock when calling a method which may materialize the llvm::Function.
llvm-svn: 56995
|
|
|
|
|
|
| |
privilege from read / write to read / executable.
llvm-svn: 56303
|
|
|
|
| |
llvm-svn: 56005
|
|
|
|
| |
llvm-svn: 55626
|
|
|
|
| |
llvm-svn: 55022
|