Displaying 20 results from an estimated 23 matches for "labellocations".
2008 Mar 30
3
[LLVMdev] Being able to know the jitted code-size before emitting
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
--------------
2008 Apr 01
2
[LLVMdev] Being able to know the jitted code-size before emitting
...ution.
>> +class SizeEmitter : public MachineCodeEmitter {
>> + MachineFunction * Fn;
>> + void* ConstantPoolBase;
>> + void* JumpTableBase;
>> + MachineConstantPool *ConstantPool;
>> + MachineJumpTableInfo *JumpTable;
>> + std::vector<intptr_t> LabelLocations;
>> + MachineCodeEmitter* MCE;
>> +
>> +public:
>> + SizeEmitter(MachineCodeEmitter* mce) {
>> + CurBufferPtr = 0;
>> + BufferBegin = 0;
>> + BufferEnd = (unsigned char*)-1;
>> + MCE = mce;
>> + }
>> +
>> + SizeEmitte...
2008 Mar 31
0
[LLVMdev] Being able to know the jitted code-size before emitting
...functions to memory for execution.
> +class SizeEmitter : public MachineCodeEmitter {
> + MachineFunction * Fn;
> + void* ConstantPoolBase;
> + void* JumpTableBase;
> + MachineConstantPool *ConstantPool;
> + MachineJumpTableInfo *JumpTable;
> + std::vector<intptr_t> LabelLocations;
> + MachineCodeEmitter* MCE;
> +
> +public:
> + SizeEmitter(MachineCodeEmitter* mce) {
> + CurBufferPtr = 0;
> + BufferBegin = 0;
> + BufferEnd = (unsigned char*)-1;
> + MCE = mce;
> + }
> +
> + SizeEmitter(std::vector<intptr_t> locations) {
&...
2008 Apr 01
0
[LLVMdev] Being able to know the jitted code-size before emitting
...izeEmitter : public MachineCodeEmitter {
>>> + MachineFunction * Fn;
>>> + void* ConstantPoolBase;
>>> + void* JumpTableBase;
>>> + MachineConstantPool *ConstantPool;
>>> + MachineJumpTableInfo *JumpTable;
>>> + std::vector<intptr_t> LabelLocations;
>>> + MachineCodeEmitter* MCE;
>>> +
>>> +public:
>>> + SizeEmitter(MachineCodeEmitter* mce) {
>>> + CurBufferPtr = 0;
>>> + BufferBegin = 0;
>>> + BufferEnd = (unsigned char*)-1;
>>> + MCE = mce;
>>> +...
2008 Apr 04
3
[LLVMdev] Being able to know the jitted code-size before emitting
...ineCodeEmitter {
>>>> + MachineFunction * Fn;
>>>> + void* ConstantPoolBase;
>>>> + void* JumpTableBase;
>>>> + MachineConstantPool *ConstantPool;
>>>> + MachineJumpTableInfo *JumpTable;
>>>> + std::vector<intptr_t> LabelLocations;
>>>> + MachineCodeEmitter* MCE;
>>>> +
>>>> +public:
>>>> + SizeEmitter(MachineCodeEmitter* mce) {
>>>> + CurBufferPtr = 0;
>>>> + BufferBegin = 0;
>>>> + BufferEnd = (unsigned char*)-1;
>>>>...
2008 Apr 05
2
[LLVMdev] Being able to know the jitted code-size before emitting
...hineFunction * Fn;
>>>>>> + void* ConstantPoolBase;
>>>>>> + void* JumpTableBase;
>>>>>> + MachineConstantPool *ConstantPool;
>>>>>> + MachineJumpTableInfo *JumpTable;
>>>>>> + std::vector<intptr_t> LabelLocations;
>>>>>> + MachineCodeEmitter* MCE;
>>>>>> +
>>>>>> +public:
>>>>>> + SizeEmitter(MachineCodeEmitter* mce) {
>>>>>> + CurBufferPtr = 0;
>>>>>> + BufferBegin = 0;
>>>>>&g...
2008 Apr 05
0
[LLVMdev] Being able to know the jitted code-size before emitting
...gt;>>>>>> + void* ConstantPoolBase;
>>>>>>> + void* JumpTableBase;
>>>>>>> + MachineConstantPool *ConstantPool;
>>>>>>> + MachineJumpTableInfo *JumpTable;
>>>>>>> + std::vector<intptr_t> LabelLocations;
>>>>>>> + MachineCodeEmitter* MCE;
>>>>>>> +
>>>>>>> +public:
>>>>>>> + SizeEmitter(MachineCodeEmitter* mce) {
>>>>>>> + CurBufferPtr = 0;
>>>>>>> + BufferBegin = 0...
2008 Apr 04
0
[LLVMdev] Being able to know the jitted code-size before emitting
...;>>> + MachineFunction * Fn;
>>>>> + void* ConstantPoolBase;
>>>>> + void* JumpTableBase;
>>>>> + MachineConstantPool *ConstantPool;
>>>>> + MachineJumpTableInfo *JumpTable;
>>>>> + std::vector<intptr_t> LabelLocations;
>>>>> + MachineCodeEmitter* MCE;
>>>>> +
>>>>> +public:
>>>>> + SizeEmitter(MachineCodeEmitter* mce) {
>>>>> + CurBufferPtr = 0;
>>>>> + BufferBegin = 0;
>>>>> + BufferEnd = (unsigne...
2008 Apr 07
2
[LLVMdev] Being able to know the jitted code-size before emitting
...gt;>> + void* ConstantPoolBase;
>>>>>>>> + void* JumpTableBase;
>>>>>>>> + MachineConstantPool *ConstantPool;
>>>>>>>> + MachineJumpTableInfo *JumpTable;
>>>>>>>> + std::vector<intptr_t> LabelLocations;
>>>>>>>> + MachineCodeEmitter* MCE;
>>>>>>>> +
>>>>>>>> +public:
>>>>>>>> + SizeEmitter(MachineCodeEmitter* mce) {
>>>>>>>> + CurBufferPtr = 0;
>>>>>>>&...
2008 Apr 07
0
[LLVMdev] Being able to know the jitted code-size before emitting
...oid* ConstantPoolBase;
>>>>>>>>> + void* JumpTableBase;
>>>>>>>>> + MachineConstantPool *ConstantPool;
>>>>>>>>> + MachineJumpTableInfo *JumpTable;
>>>>>>>>> + std::vector<intptr_t> LabelLocations;
>>>>>>>>> + MachineCodeEmitter* MCE;
>>>>>>>>> +
>>>>>>>>> +public:
>>>>>>>>> + SizeEmitter(MachineCodeEmitter* mce) {
>>>>>>>>> + CurBufferPtr = 0;
>>&...
2007 Dec 11
0
[LLVMdev] Exception handling in JIT
...tion.
> class JITEmitter : public MachineCodeEmitter {
> @@ -311,6 +391,11 @@
>
> /// Resolver - This contains info about the currently resolved
> functions.
> JITResolver Resolver;
> +
> + DwarfJITEmitter *DE;
> +
> + std::vector<intptr_t> LabelLocations;
> +
> public:
> JITEmitter(JIT &jit, JITMemoryManager *JMM) : Resolver(jit) {
> MemMgr = JMM ? JMM :
> JITMemoryManager::CreateDefaultMemManager();
> @@ -318,9 +403,14 @@
> MemMgr->AllocateGOT();
> DOUT << "JIT is managin...
2007 Dec 12
3
[LLVMdev] Exception handling in JIT
...lic MachineCodeEmitter {
>> @@ -311,6 +391,11 @@
>>
>> /// Resolver - This contains info about the currently resolved
>> functions.
>> JITResolver Resolver;
>> +
>> + DwarfJITEmitter *DE;
>> +
>> + std::vector<intptr_t> LabelLocations;
>> +
>> public:
>> JITEmitter(JIT &jit, JITMemoryManager *JMM) : Resolver(jit) {
>> MemMgr = JMM ? JMM :
>> JITMemoryManager::CreateDefaultMemManager();
>> @@ -318,9 +403,14 @@
>> MemMgr->AllocateGOT();
>> DO...
2007 Dec 10
2
[LLVMdev] Exception handling in JIT
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
2008 Feb 04
0
[LLVMdev] Exception handling in JIT
..."llvm/System/Disassembler.h"
> @@ -336,6 +339,17 @@
>
> /// Resolver - This contains info about the currently resolved
> functions.
> JITResolver Resolver;
> +
> + /// DE - The dwarf emitter for the jit.
> + JITDwarfEmitter *DE;
> +
> + /// LabelLocations - This vector is a mapping from Label ID's
> to their
> + /// address.
> + std::vector<intptr_t> LabelLocations;
> +
> + /// MMI - Machine module info for exception informations
> + MachineModuleInfo* MMI;
> +
> public:
> JITEmitter(JIT &...
2008 Feb 01
2
[LLVMdev] Exception handling in JIT
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:
2019 Jan 09
0
[PATCH v5 06/20] drm/dp_mst: Introduce new refcounting scheme for mstbs and ports
The current way of handling refcounting in the DP MST helpers is really
confusing and probably just plain wrong because it's been hacked up many
times over the years without anyone actually going over the code and
seeing if things could be simplified.
To the best of my understanding, the current scheme works like this:
drm_dp_mst_port and drm_dp_mst_branch both have a single refcount. When
2019 Jan 05
0
[PATCH v4 02/16] drm/dp_mst: Introduce new refcounting scheme for mstbs and ports
The current way of handling refcounting in the DP MST helpers is really
confusing and probably just plain wrong because it's been hacked up many
times over the years without anyone actually going over the code and
seeing if things could be simplified.
To the best of my understanding, the current scheme works like this:
drm_dp_mst_port and drm_dp_mst_branch both have a single refcount. When
2019 Jan 05
19
[PATCH v4 00/16] MST refcounting/atomic helpers cleanup
This is the series I've been working on for a while now to get all of
the atomic DRM drivers in the tree to use the atomic MST helpers, and to
make the atomic MST helpers actually idempotent. Turns out it's a lot
more difficult to do that without also fixing how port and branch device
refcounting works so that it actually makes sense, since the current
upstream implementation requires a
2019 Jan 09
27
[PATCH v5 00/20] MST refcounting/atomic helpers cleanup
This is the series I've been working on for a while now to get all of
the atomic DRM drivers in the tree to use the atomic MST helpers, and to
make the atomic MST helpers actually idempotent. Turns out it's a lot
more difficult to do that without also fixing how port and branch device
refcounting works so that it actually makes sense, since the current
upstream implementation requires a
2019 Jan 03
16
[PATCH v3 00/16] MST refcounting/atomic helpers cleanup
This is the series I've been working on for a while now to get all of
the atomic DRM drivers in the tree to use the atomic MST helpers, and to
make the atomic MST helpers actually idempotent. Turns out it's a lot
more difficult to do that without also fixing how port and branch device
refcounting works so that it actually makes sense, since the current
upstream implementation requires a