similar to: Linking LLVM IR with standard library

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

Adding back the "all recipients" - sorry, sending message from my phone, I forgot... Since my runtime is for a Pascal compiler, it has to "adapt" the C startup into a suitable Pascal environment. This means running the init portion of other modules as well as discarding the argc, argv arguments. So, I have a C main, which calls __PascalMain, which is the "main" for

I've definitely "run into this problem", and I would very much love to remove my kludges [that are incomplete, because I keep finding places where I need to modify the code-gen to "fix" the same problem - this is probably par for the course from a complete amateur compiler writer and someone that has only spent the last 14 months working (as a hobby) with LLVM]. So whilst

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

At least for Linux/Unix, there's very little you can actually achieve without at least some of the libc linked into your own system. Unless you actually write your own system call interface functions - which is dependent on the processor architecture (using `int X` [or `syscall`] in x86, perhaps `trap Y` in 68K, `swi` on ARM, etc) - values for X may vary depending on OS too, and ABI (different

It's not clear what is actually wrong from your original message, I think you need to give some more information as to what you are doing: Example source, what target GPU, compiler error messages or other evidence of "it's wrong" (llvm IR, disassembly, etc) ... -- Mats On 8 April 2016 at 09:55, Liu Xin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I built it

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

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

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

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

Hi, My requirement is something like as given below, a.c => a.obj contains a1() and a2() function b.c => b.obj contains b1() and b2() function main.c => main.obj call to a1, a2, b1, b2 Now, I want to move a1(), a2() from a.obj to b2.obj and on top of function b1() When I call b1() from main, it should call first a1, a2 and then function definition of b1 Can you please give me some

and by "right thing" i mean it can hoist if you want and it can prove it will not extend the live range. Note that VBE (very busy expressions) is a code size optimization only. It does not save time. On Tue, Feb 9, 2016 at 12:26 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > This GVN does not do that, this is correct. It is a very simple GVN. All > phi nodes are

> I think we can do such optimization with operator new, because new never returns null. This is incorrect in the case of `new (std::nothrow) ...` - the whole point of `(std::nothrow)` is to tell new that it should return NULL in case of failure, rather than throw an exception (bad_alloc). But the point here is not the actual return value, but the fact that the compiler misses that the

Thanks, Mats. Actually, it is able to generate the assembly now if I use the follow command: clang++ -O3 -S -mllvm --x86-asm-syntax=intel -mno-sse -o test_nosee.s test.cpp However, when I use g++ -O3 -o test_nosse test_nosse.s -lm to generate the executable, if gives me the following errors: Error: too many memory references for `sub' Error: too many memory references for `mov' Error:

Hello , I have build llvm from release_38 branch ( only llvm and clang ) and install it. My DYLD_LIBRARY_PATH points to installation-directory/lib. I am compiling example files for Kaleidoscope with following command : clang++ -g toy.cpp -std=c++11 `llvm-config --cxxflags --ldflags --system-libs --libs core mcjit native` -O3 -o toy but it fails with following error: Undefined symbols for

Hi, Yes I am looking for IR pass that will do insert call of functions that defined in another file. Links/suggestions that guide me to start for adding IR pass will help me so much. Regards, Deepika On Wed, Feb 10, 2016 at 1:03 PM, mats petersson <mats at planetcatfish.com> wrote: > So how do you know what you want to modify (conceptually)? > > Have you got a IR pass that you