similar to: Need help with code generation

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

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

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

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

Actually my idea was not to provide the same library for all languages, but it was to provide an API for creating a library that better fits the needs of a specific language. If you tell me that relying on the C runtime is the best way to make a runtime library and there are really few disadvantages, then ok. I also have to say that creating a runtime independent from the C runtime might make

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,

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

So, the backend should implement "__alloc" that does the same as "malloc" - or something subtly different from "malloc" - and on a Windows machine, how is it different from "HeapAlloc"? And "__write" that is same as UNIX "write", but different from "WriteFile" in Windows? And HOW do you expect the backend to implement these? By

On 23 May 2016, at 12:00, Lorenzo Laneve <lore97drk at icloud.com> wrote: > > This is the point, No, you are still failing to make a point. > High-level OO languages don't use malloc(), they use something else. That’s not entirely true. They need to get the memory that they provide to programs from somewhere. They may provide their own pool allocators, but they will often

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. > On May 23, 2016, at 1:06 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > >> On 23 May 2016, at 12:00, Lorenzo Laneve <lore97drk at icloud.com> wrote: >> >> This is the

So we come back to my earlier comment: can you produce a one-file, < 100 lines that reproduce the issue? -- Mehdi > On Mar 24, 2016, at 10:16 AM, Lorenzo Laneve <lore97drk at icloud.com> wrote: > > Those lines of code are in a function that is called before calling the moduleToObjectFile() function > > On Mar 24, 2016, at 6:07 PM, Mehdi Amini <mehdi.amini at

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

You may want to try adding this code (copy/pasted from llc.cpp): // Initialize targets first, so that --version shows registered targets. InitializeAllTargets(); InitializeAllTargetMCs(); InitializeAllAsmPrinters(); InitializeAllAsmParsers(); // Initialize codegen and IR passes used by llc so that the -print-after, // -print-before, and -stop-after options work. PassRegistry

Those lines of code are in a function that is called before calling the moduleToObjectFile() function > On Mar 24, 2016, at 6:07 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > You may want to try adding this code (copy/pasted from llc.cpp): > > // Initialize targets first, so that --version shows registered targets. > InitializeAllTargets(); >

I’m using LLVM 3.8.0, and no, it’s the precompiled version That’s why it doesn’t give me enough info for debug > On 24 Mar 2016, at 1:53 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > This code path is not likely to crash usually. Did you build LLVM yourself? Which version are you using and can you reduce the test case to be "minimal" so that someone can

I know but maybe malloc() is a bit higher level than a hypothetical __alloc(), which may be lower-level and then faster. 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. I'm just assuming that the functions we use in C such as malloc() are quite high-level interfaces and that there might

Update: Sorry my bad. I built llvm and tried it with debugging version. It was an assertion (IR/LegacyPassManager.cpp:764) saying that it expects all immutable passes to be initialized. > On Mar 24, 2016, at 2:00 AM, Lorenzo Laneve <lore97drk at icloud.com> wrote: > > I’m using LLVM 3.8.0, and no, it’s the precompiled version > That’s why it doesn’t give me enough info for

The problems happens because PMTopLevelManager::findAnalysisPassInfo(AnalysisID AID) returns nullptr in PMTopLevelManager::addImmutablePass(ImmutablePass *P). This because PassRegistry::getPassRegistry()->getPassInfo(AID) call in it returns nullptr as well. Should I probably register the pass I want to add with PassRegistry::registerPass(const PassInfo &PI, bool ShouldFree) ? I didn’t do it

Passes all need to be initialized before they are added into a pass manager. Are you calling TargetLibraryInfoWrapperPass::initializePass anywhere? -Chris > On Mar 24, 2016, at 10:41 AM, Lorenzo Laneve via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The problems happens because PMTopLevelManager::findAnalysisPassInfo(AnalysisID AID) returns nullptr in