Hi Filip
Thank you for your detailed explanation, I was actually
looking to implement an adaptive approach which is basically when some
function executed more frequently, I was trying to drop that function
and compiled and linked with new optimized function. I just did the
following -
whenever some function executed more times , I called-back
to program, so I that I could be able to call freeMachineCodeForFunction
(F) then I compiled that more frequent function with some kind of
optimization. But , still I am getting previous function signature and
not newest one. Could you please explain , why we can not use this
freeMachineCodeForFunction for this purpose. If not, how we can hook
some instruction in emitted machine code that will call back to our code
in llvm.
Thanks
With regards
Sri.
On 04/26/2014 05:39 AM, Filip Pizlo wrote:> This isn't currently supported directly. It depends on what you're
> doing, which JIT you're using, how you use modules, and to what extent
> you're relying on LLVM to do linking for you.
>
> You can't safely drop a function's code if you have other functions
in
> that module.
>
> You can't safely drop a module if there are other modules that have
> calls that you've already resolved to functions in the module
you're
> dropping unless you have your own mechanism for unlinking those calls.
>
> The MCJIT currently does support dropping the memory for a module, but
> it involves destroying the MCJIT execution engine object. This works
> best if you use your own JIT memory manager and you steal the
> executable memory from the MCJIT, and delete the MCJIT after code is
> generated. Then your own memory manager can manage the memory however
> you like. This depends on not having LLVM call instructions resolve to
> any of the functions you would be dropping. WebKit is an example of a
> system that does this. Each function gets it's own module and all LLVM
> data structures are dropped once the code is compiled. Call
> instructions are only used for intrinsics and for runtime calls;
> source level calls are implemented as patchpoints and WebKit does all
> of the linking (and unlinking).
>
> Long story short, there is no shrink-wrapped solution but it's doable
> if you're willing to get dirty.
>
> -Fil
>
> On Apr 25, 2014, at 3:44 PM, Sri <emdcdeveloper at gmail.com
> <mailto:emdcdeveloper at gmail.com>> wrote:
>
>> Hi
>> Currently , I have doing some experimental work by using
>> llvm, Is it possible to drop the machine code once it has been
>> generated for particular function while program executing. For
>> example some *void test(int)* function has been executed on native
>> machine , I want to drop the code before I start execute some other
>> function in my long running program.
>>
>> Thanks.
>>
>> With regards
>> Sri.
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140426/dbdda3af/attachment.html>
Hi Fillip
Addition to my previous mail, llvm has
recompileAndRelinkFunction function , so, once we modified the llvm
function, and pass IR to recompileAndRelinkFunction , I hope it should
be compiled and linked with previous one.
Thanks
Regards
Sri.
On 04/26/2014 12:15 PM, Sri wrote:> Hi Filip
> Thank you for your detailed explanation, I was actually
> looking to implement an adaptive approach which is basically when some
> function executed more frequently, I was trying to drop that function
> and compiled and linked with new optimized function. I just did the
> following -
> whenever some function executed more times , I called-back
> to program, so I that I could be able to call
> freeMachineCodeForFunction (F) then I compiled that more frequent
> function with some kind of optimization. But , still I am getting
> previous function signature and not newest one. Could you please
> explain , why we can not use this freeMachineCodeForFunction for this
> purpose. If not, how we can hook some instruction in emitted machine
> code that will call back to our code in llvm.
>
> Thanks
>
> With regards
> Sri.
> On 04/26/2014 05:39 AM, Filip Pizlo wrote:
>> This isn't currently supported directly. It depends on what
you're
>> doing, which JIT you're using, how you use modules, and to what
>> extent you're relying on LLVM to do linking for you.
>>
>> You can't safely drop a function's code if you have other
functions
>> in that module.
>>
>> You can't safely drop a module if there are other modules that have
>> calls that you've already resolved to functions in the module
you're
>> dropping unless you have your own mechanism for unlinking those calls.
>>
>> The MCJIT currently does support dropping the memory for a module,
>> but it involves destroying the MCJIT execution engine object. This
>> works best if you use your own JIT memory manager and you steal the
>> executable memory from the MCJIT, and delete the MCJIT after code is
>> generated. Then your own memory manager can manage the memory however
>> you like. This depends on not having LLVM call instructions resolve
>> to any of the functions you would be dropping. WebKit is an example
>> of a system that does this. Each function gets it's own module and
>> all LLVM data structures are dropped once the code is compiled. Call
>> instructions are only used for intrinsics and for runtime calls;
>> source level calls are implemented as patchpoints and WebKit does all
>> of the linking (and unlinking).
>>
>> Long story short, there is no shrink-wrapped solution but it's
doable
>> if you're willing to get dirty.
>>
>> -Fil
>>
>> On Apr 25, 2014, at 3:44 PM, Sri <emdcdeveloper at gmail.com
>> <mailto:emdcdeveloper at gmail.com>> wrote:
>>
>>> Hi
>>> Currently , I have doing some experimental work by using
>>> llvm, Is it possible to drop the machine code once it has been
>>> generated for particular function while program executing. For
>>> example some *void test(int)* function has been executed on native
>>> machine , I want to drop the code before I start execute some
other
>>> function in my long running program.
>>>
>>> Thanks.
>>>
>>> With regards
>>> Sri.
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140426/999a9837/attachment.html>
That's a good point. But it's worth noting that recompileAndRelinkFunction() and freeMachineCodeForFunction() are both vestiges of the old JIT (i.e. the "JIT" as opposed to the "MCJIT"). The old JIT is no longer actively supported. -Phil On April 26, 2014 at 9:47:05 AM, Sri (emdcdeveloper at gmail.com) wrote: Hi Fillip Addition to my previous mail, llvm has recompileAndRelinkFunction function , so, once we modified the llvm function, and pass IR to recompileAndRelinkFunction , I hope it should be compiled and linked with previous one. Thanks Regards Sri. On 04/26/2014 12:15 PM, Sri wrote: Hi Filip Thank you for your detailed explanation, I was actually looking to implement an adaptive approach which is basically when some function executed more frequently, I was trying to drop that function and compiled and linked with new optimized function. I just did the following - whenever some function executed more times , I called-back to program, so I that I could be able to call freeMachineCodeForFunction (F) then I compiled that more frequent function with some kind of optimization. But , still I am getting previous function signature and not newest one. Could you please explain , why we can not use this freeMachineCodeForFunction for this purpose. If not, how we can hook some instruction in emitted machine code that will call back to our code in llvm. Thanks With regards Sri. On 04/26/2014 05:39 AM, Filip Pizlo wrote: This isn't currently supported directly. It depends on what you're doing, which JIT you're using, how you use modules, and to what extent you're relying on LLVM to do linking for you. You can't safely drop a function's code if you have other functions in that module. You can't safely drop a module if there are other modules that have calls that you've already resolved to functions in the module you're dropping unless you have your own mechanism for unlinking those calls. The MCJIT currently does support dropping the memory for a module, but it involves destroying the MCJIT execution engine object. This works best if you use your own JIT memory manager and you steal the executable memory from the MCJIT, and delete the MCJIT after code is generated. Then your own memory manager can manage the memory however you like. This depends on not having LLVM call instructions resolve to any of the functions you would be dropping. WebKit is an example of a system that does this. Each function gets it's own module and all LLVM data structures are dropped once the code is compiled. Call instructions are only used for intrinsics and for runtime calls; source level calls are implemented as patchpoints and WebKit does all of the linking (and unlinking). Long story short, there is no shrink-wrapped solution but it's doable if you're willing to get dirty. -Fil On Apr 25, 2014, at 3:44 PM, Sri <emdcdeveloper at gmail.com> wrote: Hi Currently , I have doing some experimental work by using llvm, Is it possible to drop the machine code once it has been generated for particular function while program executing. For example some void test(int) function has been executed on native machine , I want to drop the code before I start execute some other function in my long running program. Thanks. With regards Sri. _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140426/0c001b1c/attachment.html>