similar to: [LLVMdev] Explicit register usage in LLVM assembly

Hello Yiannis, You could write a custom backend that doesn't allocate %r15 for general usage. The normal way to do this is to set up a custom calling convention for all functions that keeps a sentinel in %r15 so that it always holds the sentinel. This is how new operating systems are supported with custom ABIs. The only problem is that you cannot be assured that %r15 stays put between

On 04/02/2011 06:26 PM, Samuel Crow wrote: > Hello Yiannis, > > You could write a custom backend that doesn't allocate %r15 for general usage. > The normal way to do this is to set up a custom calling convention for all > functions that keeps a sentinel in %r15 so that it always holds the sentinel. > This is how new operating systems are supported with custom ABIs. The

Sorry for double-posting to the list, The citation is the following (this time with a url to the paper): K. Sagonas, C. Stavrakakis, and Y. Tsiouris. "ErLLVM: An LLVM backend for Erlang"[1]. In Eleventh ACM SIGPLAN Erlang Workshop, September 2012. ACM Press. Thanks! Yiannis [1]: http://erllvm.softlab.ntua.gr/files/erlang03-sagonas.pdf On 09/07/2012 08:13 PM, Yiannis Tsiouris wrote:

ping. :-) On 09/07/2012 08:24 PM, Yiannis Tsiouris wrote: > [...] > The citation is the following (this time with a url to the paper): K. > Sagonas, C. Stavrakakis, and Y. Tsiouris. "ErLLVM: An LLVM backend > for Erlang"[1]. In Eleventh ACM SIGPLAN Erlang Workshop, September > 2012. ACM Press. > > [1]: http://erllvm.softlab.ntua.gr/files/erlang03-sagonas.pdf >

On 04/03/2011 12:43 AM, Frits van Bommel wrote: > On Sat, Apr 2, 2011 at 9:46 PM, Yiannis Tsiouris > <yiannis.tsiouris at gmail.com> wrote: > >> I am not sure i made myself clear about what i want. I was wondering >> if there >> is a way to communicate to LLVM's register allocator and define which >> registers are pre-coloured and should not be used

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/08/2011 10:30 PM, Frits van Bommel wrote: > On 8 July 2011 21:10, Yiannis Tsiouris <yiannis.tsiouris at gmail.com> wrote: >> The problem with that is the case of an 'invoke' call. According to the >> semantics of the invoke instruction the return value is not available when >> a stack unwind happens. From

On Sun, Apr 3, 2011 at 2:58 AM, David Terei <davidterei at gmail.com> wrote: > Hi Yiannis, > > As has been said GHC had this problem (I'm the author of GHC's LLVM > backend). GHC uses 4 pinned registers on x86-32 and 16 on x86-64. The > solution is to use a custom calling convention. I would argue that > this is a better solution then having the registers

On 8 July 2011 21:10, Yiannis Tsiouris <yiannis.tsiouris at gmail.com> wrote: > The problem with that is the case of an 'invoke' call. According to the > semantics of the invoke instruction the return value is not available  when > a stack unwind happens. From the Language Reference Manual: >  "For the purposes of the SSA form, the definition of the value returned by

On Sat, Apr 2, 2011 at 9:46 PM, Yiannis Tsiouris <yiannis.tsiouris at gmail.com> wrote: >  I am not sure i made myself clear about what i want. I was wondering > if there > is a way to communicate to LLVM's register allocator and define which > registers are pre-coloured and should not be used for allocation. Do you really need that, or would it be enough to be able to get

On 9/10/12 5:29 PM, Yiannis Tsiouris wrote: > ping. :-) I've been on vacation since August 28 and disabled llvmdev delivery so that I wouldn't get flooded with emails while I was gone, so I didn't see your message. I've added the entry to the publications page, but I haven't made a separate page for the abstract. Is that alright, or would you like an abstract page

Hi Yiannis, As has been said GHC had this problem (I'm the author of GHC's LLVM backend). GHC uses 4 pinned registers on x86-32 and 16 on x86-64. The solution is to use a custom calling convention. I would argue that this is a better solution then having the registers completely reserved as in the middle of a function llvm can spill those registers to free them up for temporary use. Also,

Yiannis, Pedro, I'm not an expert here. Taking closer look I see that it makes sense to do this cleanup job in doFinalization() of the pass, which requested GC info. So the current fix seems to be ok and all external clients will need to do cleanup directly doing the same jobs as Printer::doFinalization() does now. By the way, I've just noticed that comments for GCModuleInfo::clear()

Hi, After rebasing my local LLVM repo to ToT, I noticed that the finishAssembly function is not executed and, thus, the stack map is not printed at all. Is this a known issue or I 'm doing something wrong? I used a custom GCMetadataPrinter plugin but I reproduced this using the builtin "ocaml" GC plugin and the attached file (actually, any simple ll file that uses

Pedro, Yiannis, What's about the usage case, when LLVM is used as a library and the user implements its custom pass, which dump the code (implemented as a FunctionPass, but not as Printer)? You also missed in your changes the declaration of llvm::createGCInfoDeleter() in include/llvm/CodeGen/Passes.h -Dmitry. On Mon, Feb 18, 2013 at 9:34 PM, Pedro Artigas <partigas at apple.com>

Sorry for the triple-posting! :-$ On 02/14/2013 04:30 PM, Yiannis Tsiouris wrote: > On 02/10/2013 08:47 PM, Yiannis Tsiouris wrote: >> After rebasing my local LLVM repo to ToT, I noticed that the >> finishAssembly function is not executed and, thus, the stack map is not >> printed at all. >> >> Is this a known issue or I 'm doing something wrong? >>

Ping for this. On 02/10/2013 08:47 PM, Yiannis Tsiouris wrote: > After rebasing my local LLVM repo to ToT, I noticed that the > finishAssembly function is not executed and, thus, the stack map is not > printed at all. > > Is this a known issue or I 'm doing something wrong? > > I used a custom GCMetadataPrinter plugin but I reproduced this using the > builtin

Hi , Can someone commit the attatched (cleanup) patch for r175528? Thanks, yiannis On 02/25/2013 08:11 PM, Dmitry Babokin wrote: > Yiannis, Pedro, > > I'm not an expert here. Taking closer look I see that it makes sense > to do this cleanup job in doFinalization() of the pass, which > requested GC info. So the current fix seems to be ok and all external > clients will

Hi, We 've been working on an LLVM backend for High Performance Erlang (HiPE) [1], the native code compiler of Erlang/OTP [2]. ErLLVM [3] targets the X86 and AMD64 architectures for now but there is some ongoing work from a team on the Uppsala University to also support ARM. In our implementation, we have paid special attention on retaining ABI-compatibility with the Erlang Runtime System in

Hi, Following Chris' advice, I will rebase the patches and break them in 3 distinct emails (one at a time) in order to be easier for a reviewer to approve/comments. Please note that the three patches while being code-wise independent, they 're strongly-connected *semantically*, meaning that including just a subset of these patches to LLVM's code base is quite weak if the others are

Hi Dmitry, On 02/23/13 19:10, Dmitry Babokin wrote: > What's about the usage case, when LLVM is used as a library and the > user implements its custom pass, which dump the code (implemented as a > FunctionPass, but not as Printer)? Hm, I haven't thought of that... I'll take a better look and try to find a more suitable solution. Any suggestion is more than welcome! :-)