similar to: [LLVMdev] Stack implementation

Piotr Kaleta <piotrek.kaleta at gmail.com> writes: > I'm translating the source of stack-based virtual machine into LLVM IR and > my plan is to implement the stack in LLVM IR (using alloca/load/store) in > order to emulate the VM's stack and then use the optimization phase > "mem2reg". Therefore I'm going to have a stack pointer that points to the > top

I'm implementing a lazy functional language and I need to allocate nodes on the heap. From what I've read LLVM supports only the 'alloca' instruction which allows to allocate memory on the stack. Is this true and and if so, what is the preferred way to solve my problem? -- Piotr Kaleta -------------- next part -------------- An HTML attachment was scrubbed... URL:

[I'm not subscribed to this list, please CC me on replies] Hi, well, the topic says it all ;) I want to know if it's safe to use them (yes, i know it's not safe, but if someone says 'they fucked my computer' i will know i can't use them. If noone says anything i will find someone to test them ;)) Thanks. -- Piotrek irc: #debian.pl Mors Drosophilis melanogastribus!

Hi, I am unsuccessfully trying to connect from host to containers dbus. Inside container dbus socket file is visible as /run/dbus/system_bus_socket. The problem is that /run is mounted as tmpfs in container (by systemd on container) and thus the directory content is not visible outside the container. Is there any way to make this file visible also outside the container? Regards, Piotrek

The saga continues. I've been tracking the interface changes and merging them with the refactoring work I'm doing. I got as far as building stage3 of llvm-gcc but the object files from stage2 and stage3 differ: warning: ./cc1-checksum.o differs warning: ./cc1plus-checksum.o differs (Are the above two ok?) The list below is clearly bad. I think it's every object file in the

hi, i'm new to R and i discovered that for years people are complaining about lacking of very basic and hopefully simple things, like multiline comment, some marker for 'command doesn't end at this line' etc. so my question is why some of those things are still not implemented? is it because of compatibility/policy reasons? is R syntax done and any extensions are forbidden?

Compile the following functions with "-O3 -target i386" (see <https://godbolt.org/z/VmKlXL>): long long div(long long foo, long long bar) { return foo / bar; } On the left the generated code; on the right the expected, properly optimised code: div: # @div push ebp | mov ebp, esp | push dword ptr [ebp + 20] | push

Compile the following functions with "-O3 -target i386-win32" (see <https://godbolt.org/z/exmjWY>): __int64 __fastcall div(__int64 foo, __int64 bar) { return foo / bar; } On the left the generated code; on the right the expected, properly optimised code: push dword ptr [esp + 16] | push dword ptr [esp + 16] | push dword ptr [esp + 16] |

Hi, I've been reading the list and it seems the answer to my (soon to be asked question) is no, at least with 0.99, but I'll ask to be sure. I have following setup: new mail goes to ~/Mail/Maildir, except for mailing lists which are moved by procmail to ~/Mail/mailing_lists/name, spam which goes to ~/Mail/spam. Read mail is moved by mutt to ~/Mail/read. Everything is in maildir format.

Dear All, I encountered the following problem: fun1 <- function(x){ 2*cos(x) } >library(debug) > mtrace(fun1) > fun1(0.1) Error in all.levs[[j]] : subscript out of bounds > sessionInfo() R version 2.5.0 (2007-04-23) i386-pc-mingw32 locale: LC_COLLATE=Polish_Poland.1250;LC_CTYPE=Polish_Poland.1250; LC_MONETARY=Polish_Poland.1250;LC_NUMERIC=C;LC_TIME=Polish_Poland.1250 attached

(Tested using a Linux bzImage, with and without an initrd.) Per shuffle_and_boot documentation, %ecx must contain the descriptor list byte length, but it's set with such list end address instead. Fix. Signed-off-by: Ahmed S. Darwish <darwish.07 at gmail.com> -- core/bcopy32.inc | 2 ++ core/bcopyxx.inc | 2 ++ core/bootsect.inc | 8 +++++--- core/runkernel.inc |

Thank You, It means vmovdqa64 zmm22, zmmword ptr [rip + .LCPI0_0] # zmm22 = [8,9,10,11,12,13,14,15] zmm22 will contain 64 bit constant values which are indexes here zmm22=8, 9, 10, 11, 12,13,14,15. not the values loaded from these locations. and zmm2 contains constant 4000. so, vpmuludq zmm14, zmm10, zmm2 ; will multiply the indexes values with 4000, as for array b the stride is 4000. zmm14=

Hi, for interested in participation on finishing new HTB developement I created simple docs regarding it. It is some insight into CBQ and HTB workings and problems. See luxik.cdi.cz/~devik/qos/htb/v3/

Hi folks, this summer I will work with Richard Smith on clang devirtualization. Check out our proposal: https://docs.google.com/document/d/1f2SGa4TIPuBGm6y6YO768GrQsA8awNfGEJSBFukLhYA/edit?usp=sharing And modified LangRef http://reviews.llvm.org/D11399 You can also check out previous disscussion that was started before our proposal was ready -

So, in hacking on mem2reg I noticed that it doesn't actually implement optimizations enabled by lifetime markers. I thought I might take a stab at teaching it about them, but I'm left with some questions about the semantics. Much of this may have been hash out when they were added, and if so I'll appreciate your help educating me, and maybe we can come up with improved documentation to

Hello, I am experiencing problems, when trying to assemble these two x86-64 Opcodes "add r64, imm32" "imul r64, r64, imm32" When having the most significant bit set for imm32, for example: "add rax, 0x80000000", "add rax, 0xffffffff", ... "imul rbx, rsi, 0x80000000", "imul rbx, rsi, 0xffffffff", ... The Error Message I receive is the

Following a question on StackOverflow [1], I was wondering if for big allocations, LLVM would "delay" the allocation or rather perform it upfront. The following code was thus submitted to the LLVM Try Out page: void doSomething(char*,char*); void function(bool b) { char b1[1 * 1024]; if( b ) { char b2[1 * 1024]; doSomething(b1, b2); } else { char

Hi! I've attached my first week of work as a patchset for review. This is also available on Github [1]. By next Monday I intend to (more or less) finish up the preliminary parts concerning the codegen; and start working on the runtime (so that I can do a basic sanity check). [1] https://github.com/sanjoy/llvm/tree/segmented-stacks -- Sanjoy Das http://playingwithpointers.com

On 11-05-30 07:20 AM, Sanjoy Das wrote: > Hi! > > I've attached my first week of work as a patchset for review. This is > also available on Github [1]. > > By next Monday I intend to (more or less) finish up the preliminary > parts concerning the codegen; and start working on the runtime (so that > I can do a basic sanity check). Thanks!. Some quick notes *) Maybe you

I threw together a patch which implements this (attached.) If we decide that this is actually a legal transform, I'm happy to post this for review. In addition to the version proposed here, I also implemented a case where a trivially escaped alloca's address is not equal to any other value. I believe both are valid, but we should confirm. Philip On 09/24/2015 02:34 PM, Aaron