search for: lacsap

Even if I turn to -O0 [in other words, no optimisation passes at all], it takes the same amount of time. The time is spent in 12.94% lacsap lacsap [.] llvm::SDNode::use_iterator::operator== 7.68% lacsap lacsap [.] llvm::SDNode::use_iterator::operator* 7.53% lacsap lacsap [.] llvm::SelectionDAG::ReplaceAllUsesOfValueWith 7.28% lacsap lacsap [.] llvm::SDNode::use...

...conds is a long time to compile 37 lines of relatively straight forward code - even the Pascal compiler on PDP-11/70 that I used at my school in 1980's was capable of doing more than 1 line per second, and it didn't run anywhere near 2.5GHz and had 20-30 users anytime I could use it...] ../lacsap -no-memcpy -tt longcompile.pas Time for Parse 0.657 ms Time for Analyse 0.018 ms Time for Compile 1.248 ms Time for CreateObject 48803.263 ms Time for CreateBinary 48847.631 ms Time for Compile 48854.064 ms compared with: ../lacsap -tt longcompile.pas Time for Parse 0.455 ms Time for Analyse 0.013...

Hi, I have a LLVM IR file generated for a different source language (Not C). I have added a rand() function in it to generate random numbers. I compiled the .ll file to .o using clang. However, when I execute the .o file all generated numbers are zeros. How should I link the .ll file with the standard library for the clang to generate the random numbers? Thanks -Shilpa -------------- next

...*** [Makefile:2216: install-recursive] Error 1 make[1]: Leaving directory '/tmp/libguestfs-1.38.2' make: *** [Makefile:2873: install] Error 2 what the problem is or could be ? is there any other way outside libguestfs to access the contents of the virtual machine vhd/vhdx disk ? regards, lacsaP.

...(more or less directly) > interface to the C library. It's relatively easy [as long as your compiler > has sane calling conventions, etc] and solves the immediate problem without > too much effort. > >> > >> What I did: > >> https://github.com/Leporacanthicus/lacsap/tree/master/runtime > >> > >> Originally, my runtime was one monolithic .c file, with a couple dozen > functions, but as it grew, I decided to move it into separate parts. > >> > >> Obviously, there are OTHER solutions, but I don't know of a way that >...

2015-08-17 11:26 GMT-07:00 Mehdi Amini <mehdi.amini at apple.com>: > Hi, > > On Aug 17, 2015, at 12:13 AM, deadal nix via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > 2015-08-16 23:21 GMT-07:00 David Majnemer <david.majnemer at gmail.com>: > >> >> >> Because a solution which doesn't generalize is not a very powerful

If you plan on calling C runtime library functions, you probably want to do what I did: Cheat, and make a libruntime.a (with C functions to do stuff your compiler can't do natively) and then link that using clang or gcc. https://github.com/Leporacanthicus/lacsap/blob/master/binary.cpp#L124 At some point, I plan to replace my runtime library with native Pascal code, at which point I will be able to generate the ELF binary straight from my compiler without the runtime library linking in the C runtime library, but that's not happening anytime real soon....

I'm given to understand that the recommendation these days is to use libOption instead of cl::opt, on the grounds that it has a number of advantages including more control of which options are made available. Is there any information available on how to use libOption, any documentation or example programs? Do any existing programs use it except the clang driver programs? Those customise their

...ed some start-up code, so calling `_start` at that point isn't such a terrible thing. I use the C compiler as a linker, so I just call my language's startup `main` and be done with it. But you'll probably find yourself implementing something like this: https://github.com/Leporacanthicus/lacsap/blob/master/runtime/main.c either way, even if it's not precisely called `main`, and isn't written in C. Yes, it's necessary to call `_start` or equivalen, if you want to `stdin` and `stdout`, to initialize those - but sooner or later, you'll end up wanting to buffer I/O a little b...

Thanks, Reid. When you say the frontend needs to know about how LLVM implements it, do you mean, the Function* type in LLVM, and in which order you add to the arguments array when building this type? Thank you for the video link, just reading the abstract I see this is the way to go. However, as I finished typing the sentence, I wonder if this means clang and/or llvm may be a runtime dependency.

This is the point, High-level OO languages don't use malloc(), they use something else. My idea was a C API with implementations of functions: For example Assuming I need to implement a function which allocates a new object. The API provides a really basic allocator function I can use to implement the complete function the high-level language needs. void *__newobject(int class_size) { void

...me start-up code, so calling `_start` at that point isn't such a terrible thing. I use the C compiler as a linker, so I just call my language's startup `main` and be done with it. But you'll probably find yourself implementing something like this: > https://github.com/Leporacanthicus/lacsap/blob/master/runtime/main.c > either way, even if it's not precisely called `main`, and isn't written in C. > > Yes, it's necessary to call `_start` or equivalen, if you want to `stdin` and `stdout`, to initialize those - but sooner or later, you'll end up wanting to buffer...

You guys are saying that the library which defines the runtime library is written in C for many languages. The problem is that such functions are in the libc and so the object files have to be linked against the **entire** libc. Sorry if I'm wrong but isn't it a little inefficient or hard to handle? With "hard to handle" I mean the entry point: if I use C's I/O operations,

On 23 May 2016, at 12:16, Lorenzo Laneve <lore97drk at icloud.com> wrote: > > I'm not talking about a new library instead of the libc, I'm talking about letting people create a library optimized for a specific frontend, regardless of the target. It sounded as if you were talking about a library that sits underneath such a thing. Lots of languages have their own runtime

Now, I am using LLVM-3.3 do some process with functions, however there are some difficult things I can't handle by myself. So, I want get your help to get it down properly. Q1. There is a function declaration: call i32 @create(i64* %tid, %union.t* %pab, i8* (i8*)* @worker, i8* null) // callInst Store instruction goes like this: store i8* (i32, double, i32*)* %fp, i8* (i32, double, i32*)**

On 23 May 2016, at 10:13, Lorenzo Laneve <lore97drk at icloud.com> wrote: > > I know but maybe malloc() is a bit higher level than a hypothetical __alloc(), which may be lower-level and then faster. How? > And malloc() is contained in the libc as Matthias said and so maybe a program using malloc() even for a non-C language linking against the crt is needed. On many *NIX

I'd like to make my compiler independent, just like Clang. Doesn't Clang call llc and then system's ld by itself? I don't want my compiler to depend by any other program. I guess there will be a class in the llvm library that generates the object files based on the system's triple and data layout, and then call the system's ld? > On Mar 19, 2016, at 11:48 AM, Bruce

Hi, I've try to enable the new loss concealment code with celt-0.6.1. I've run "configure --enable-new-plc" but I've got a missing plc.c file while compiling. It is also missing for version 0.6.0. Can you release this missing file? Thank you, Pascal CRC