search for: zasenko

...y point). Actually it may be more than one entry point so all dependent functions and global values must be extracted. I've tried llvm-extract tool but it can't do work recursively. Maybe it would be good to write some Call Graph pass or something. Any thoughts? Thanks in advance, Alexey Zasenko -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161027/3d556780/attachment.html>

Hi all, Is it planned to add support of rotations to IR? Thanks, Aleksey Zasenko -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151119/c897b935/attachment.html>

...ly correct. The second is the CallGraph analysis within DSA. You should be able to find a copy for LLVM 3.7 or LLVM 3.8 here (https://github.com/jtcriswell/safecode-llvm37) and here (https://github.com/jtcriswell/llvm-dsa). Regards, John Criswell > > > Thanks in advance, > Alexey Zasenko > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -- John Criswell Assistant Professor Department of Computer Science, University of Rochester http://www.cs...

...ails at /lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:273. I noticed that R_X86_64_PC32 relocations are used only within .eh_frame section. Why aren't R_X86_64_64 relocations used in that case? Is there any working solution of this problem? Thank you in advance. -- Best regards, Alexey Zasenko -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140526/1cc9b0e1/attachment.html>

...6*) DW_AT_external [DW_FORM_flag_present] (true) There are lots of subprogram records like this. Any ideas what may be done to fix that? My debugger config: GNU gdb (GDB) 7.10.1 This GDB was configured as "i686-w64-mingw32". OS : Win7 64-bit -- Best regards, Alexey Zasenko -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170404/b8ff0140/attachment.html>

...ails at /lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:273. I noticed that R_X86_64_PC32 relocations are used only within .eh_frame section. Why aren't R_X86_64_64 relocations used in that case? Is there any working solution of this problem? Thank you in advance. -- Best regards, Alexey Zasenko _______________________________________________ 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....

...ot to use GlobalContext object and created my own one. This method didn't help - GlobalContext was still lazy creating by PseudoSourceValue ctor . I would understand to know if I did something wrong or is this a bug? I made tests both on 3.1 and trunk builds. Thank you in advance! -- Alexey Zasenko Visutech System Ltd. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121213/29f48ef2/attachment.html> -------------- next part -------------- #include <iostream> #include <llvm/LLVMContext.h>...

That's encouraging. Assuming that all access to the JITted code is going to be done through a function pointer, and all JIT code is ephemeral, why is the object container format important? In fact, why is it even needed? I found it somewhat odd that MCJIT generates an object file for even the JIT case. To answer my own question, could it be that advanced JIT's may need/want to use things