similar to: [LLVMdev] Function attributes and bytecode

While writing bindings to LLVM for another language via the c api I noticed that LLVMAlignment and LLVMStackAlignment do not use 1<<x like all the others, but 31<<x and 7<x respectively (see below, or here: http://llvm.org/docs/doxygen/html/Core_8h_source.html#l00148). It's likely this is as it is intended, but it does look out-of-place enough that I thought it might be a

Hi everybody, I'm currently looking at LLVM as a possible back-end to a dynamic programming system (in the tradition of Smalltalk) we are developing. I have read most of the llvmdev archives, and I'm aware that some things are 'planned' but not implemented yet. We are willing to contribute the code we'll need for our project, but before I can start coding I'll have to

Hi, Is there any way to support either stack branching or heap-allocated stack frames in llvm? What I am after is non-preemptive threading support (as in Modsim, but I have also written a small library in asm to allow this in C), where a function can "suspend" itself and resume execution later. I was excited to find llvm as I thought it would be an excellent back end for a language

On Fri, Oct 22, 2004 at 03:18:00PM +0200, Marc Ordinas i Llopis wrote: > I'm currently looking at LLVM as a possible back-end to a dynamic > programming system (in the tradition of Smalltalk) we are developing. Neat! > I have read most of the llvmdev archives, and I'm aware that some > things are 'planned' but not implemented yet. We are willing to > contribute

Hello, I have the following simple C code below. It should return '8' as a result. But the returned result is false as it returns '1'. When I remove the line of '__attribute__((noinline))' , the returned results are correct '8'. Any idea? Please advice as I need to get the assembly code of the 'getTexSize' function alone. Note: I compile using the

Hi Markus, Thanks for this interesting patch! It looks okay to me, but our C/C++ Front End guru is away right now. I would rather defer to him on this patch. He might not get to it until next week so I just wanted to let you know that there might be a bit of a delay before this patch hits mainline. I've already committed your configure changes. Reid. On Wed, 2004-12-22 at 21:42, Markus

On Fri, 22 Oct 2004, Marc Ordinas i Llopis wrote: > Hi everybody, Hi! > I'm currently looking at LLVM as a possible back-end to a dynamic > programming system (in the tradition of Smalltalk) we are developing. I Very cool! > have read most of the llvmdev archives, and I'm aware that some things > are 'planned' but not implemented yet. We are willing to

Markus F.X.J. Oberhumer wrote: > Hello folks, > > with the small patch attached below the whole llvm toolchain (llvm & llvm-gcc) > will compile and run under AMD64 Linux in native 64-bit LP64 mode. > > This means that compilation, bytecode management and CWriter output all work > as expected. Of course there is no JIT, and the bytecode interpreter is still > very

On Thu, 25 Aug 2005, Nicola Lugato wrote: > Another question: > What's the best way in general to implement interfaces (like java ones > for example)? Any hint ? I'm just in the dark with this. Along with what the others said, you might find these notes useful: http://nondot.org/sabre/LLVMNotes/MSILObjectModel1.txt http://nondot.org/sabre/LLVMNotes/MSILObjectModel2.txt Which

On Sun, 8 May 2005, Markus F.X.J. Oberhumer wrote: > Chris Lattner wrote: >> On Sat, 7 May 2005, Markus F.X.J. Oberhumer wrote: >>> but looking at the disassembly suggests that this might mainly be an issue >>> of x86 codegen, which is rather young as compared to other compilers. >> If you're testing on X86, I would be strongly suspious of the X86 backend,

On Sat, 7 May 2005, Markus F.X.J. Oberhumer wrote: > Chris Lattner wrote: >> On Sat, 7 May 2005, Markus F.X.J. Oberhumer wrote: >> >>> As I've just seen that there are some things going on w.r.t the long >>> needed implementation of calling conventions, may I also ask if it's >>> possible to address inlining at the same moment (i.e. attributes

Hi! i'm tring to figure out how classes and dependencies can be mapped to llvm. I've read on docs that nesting can be used: class base { int Y; }; class derived : base { short Z; }; becomes: %base = type { int } %derived = type { %base, short } That's ok, but now the question is: how do i encode a function that takes "base" type so that it also takes "derived"

Are you suggesting that we have "always_inline" and "never_inline" keywoards that can be attributed to functions? If so, why do you want this level of control? What's wrong with the current inlining pass? Reid. On Sat, 2005-05-07 at 20:34 +0200, Markus F.X.J. Oberhumer wrote: > As I've just seen that there are some things going on w.r.t the long > needed

On Thu, Dec 23, 2004 at 06:42:02AM +0100, Markus F.X.J. Oberhumer wrote: > with the small patch attached below the whole llvm toolchain (llvm & > llvm-gcc) will compile and run under AMD64 Linux in native 64-bit LP64 > mode. Sounds great! I'll add it to the list of supported platforms. > This means that compilation, bytecode management and CWriter output > all work as

On Mon, Jul 8, 2019 at 4:39 PM David Blaikie <dblaikie at gmail.com> wrote: > There isn't any magic command for this - you'd have to write some C++ > code/a custom LLVM optimization pass. > > Though, that said - perhaps it should just be a runtime parameter where > you rely on LLVM to inline/optimize things away? You could do some > relatively smaller code

Hi, I''ve a problem and I don''t know if it is solvable with activeLDAP. Here is an example of the tree structure of our LDAP server. The structure isn''t exactly like that, but is similare and I can already access almost any informations of a user when I''m logging as this user. The probleme come when using the belong_to, has_many and ldap_mapping has you will

Do you have some pointers on how to do it? Take a file like sort.cc above and generate a JIT module. Does llc <https://llvm.org/docs/CommandGuide/llc.html> help with this? What library function can we use to load an existing IR module file into my JIT runtime module to compile them together? On Tue, Jul 9, 2019 at 4:17 PM David Blaikie <dblaikie at gmail.com> wrote: > Ah, no, sort

Thanks David! I am not clear on how to achieve this though. Could you give more info on this? I expect something like this: sort.cc file: bool Compare(void* a, void* b) { return false; } void SortFunc(void* arr, int len) { std::sort(arr, len, &Compare) } $MAGIC_COMMAND sort.cc -o a.llvm a.llvm is a bytecode which can be loaded at runtime in my JIT module and write some code to

On Sun, 2005-05-08 at 02:52 +0200, Markus F.X.J. Oberhumer wrote: > Put simply, the inliner is too greedy and nice little leaf functions > suddenly run out of CPU registers. Even gcc 3.4 with -funit-at-a-time > started inlining too much, but at least I can tell gcc where to stop. > This whole noinline issue may be somewhat X86 specific, though. This is where a register allocator

On Sat, 7 May 2005, Markus F.X.J. Oberhumer wrote: > As I've just seen that there are some things going on w.r.t the long needed > implementation of calling conventions, may I also ask if it's possible to > address inlining at the same moment (i.e. attributes always_inline and > noinline, but maybe LLVM wants a finer grained level here) ? They really are different issues.