[LLVMdev] Drop the machine code while executing
Sri
emdcdeveloper at gmail.com
Sun Apr 27 13:45:31 PDT 2014
Hi Gael
Thanks for your guidance . I will try patchpoint method
to solve this issue .
Thanks
With regards
Sri.
On 04/27/2014 07:15 PM, Gaël Thomas wrote:
>
> Hi Sri,
>
> If main is compiled before the call to recompile, it will call test
> with a direct call. After the update of the test function, the second
> call site is not updated. To call the new test, you can either call
> test with an indirect call, recompile also main, or use a patchpoint
> to update the second call. The last solution is probably the best one.
>
> Gaël
>
> Le 27 avr. 2014 20:01, "Sri" <emdcdeveloper at gmail.com
> <mailto:emdcdeveloper at gmail.com>> a écrit :
>
> Hi Phil
> Thank you for your clarification, Actually I compiled
> VMKit 3.2 with llvm 3.2 and trying do
> /*recompileAndRelinkFunction*/() . Could you please verity the
> following things to me. For instance , code need to be executed
> as follows
> */main()/**/{/**/
> /**/ test()/**/;/**/
> /**/differentTest();/**/
> /**/ test();/**/
> /**/ }/*
> as soon as I executed the first *test*() function , I modified
> the llvm IR ( modified some instruction) of test , then when I
> execute differentTest(), I used /recompileAndRelinkFunction/() to
> link the modified test() before I execute the last test()
> function. Actually , I was expecting the different result when I
> was executing the last *test*() function but unfortunately it
> execute the previous test() function not modified one. How can I
> use this /*recompileAndRelinkFunction() to modify the native code
> during the execution.
>
> Thanks .
>
> With regards
> Sri.
> */
> On 04/26/2014 06:19 PM, Filip Pizlo wrote:
>> 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
>> <mailto: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
>>>>> <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
>>>>
>>>
>
>
> _______________________________________________
> 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/20140427/a5d3b85e/attachment.html>
More information about the llvm-dev
mailing list