similar to: [LLVMdev] Explicitly Managed Stack Frames

On Wed, 11 Jan 2006, Ben Chambers wrote: > I was wondering what the current state of this (explicitly managed stack frames) > is. Is it being worked on? If not, how hard do you think it would be for me to > add it? I'm not sure what you mean. It depends on correct tail calls, but no other LLVM-level support. > I am more than willing to work on it, but don't have any

Chris Lattner wrote: > On Wed, 11 Jan 2006, Ben Chambers wrote: > >> I was wondering what the current state of this (explicitly managed >> stack frames) >> is. Is it being worked on? If not, how hard do you think it would >> be for me to >> add it? > > > I'm not sure what you mean. It depends on correct tail calls, but no > other

Hi everybody, I'd like to try implementing a pass that transforms all functions (and function calls, returns, etc.) to CPS, so that TCO can get rid of all (or most of) the function calling overhead (because, as you probably know, the side effect of using CPS is that all function calls become tail calls). That being said, and since I'm pretty new to LLVM, I'd like to ask a couple

Just out of curiosity, now that explicitly managed stack frames [1] are possible (given support in the code generators), is the stack register freed for other uses when the LLVM system stack isn't being used? Sandro [1] http://nondot.org/sabre/LLVMNotes/ExplicitlyManagedStackFrames.txt

> [1] http://nondot.org/sabre/LLVMNotes/ExplicitlyManagedStackFrames.txt Interesting. Something like this is more then sufficient for implementing by value structure passing at the llvm level :-) Cheers, -- Rafael Avila de Espindola Google Ireland Ltd. Gordon House Barrow Street Dublin 4 Ireland Registered in Dublin, Ireland Registration Number: 368047

William Morgan wrote: > Hi all, > > At the bottom of chapter 8 of the tutorial, on the topic of closures, > mentions that there are "often better ways to implement these features > than explicit stack frames". Does anyone know what techniques this > cryptic statement might be referring to? > > Thanks! > I would say it means to have a "stackless"

> Is there a reason you can't use the algorithm from the paper "A Correspondence between Continuation Passing Style and Static Single Assignment Form" to convert your IR to LLVM's SSA IR? Yes, there are a few reasons. Undoing the CPS transformation earlier in the pipeline would mean that we are using LLVM's built-in stack. The special layout and usage of the stack in

On Mon, 25 Oct 2004, Marc Ordinas i Llopis wrote: > Misha Brukman wrote: > >>1. Opcodes and intrinsics > >> > > That's not really correct. The intrinsics such as llvm.frameaddress and > > llvm.returnaddress have no equivalents in LLVM opcodes -- the meaning of > > the intrinsics is specifically machine-dependent, and LLVM (and its > > opcodes) are

Given my recent posts, I think it's obvious that I'm trying to figure out how to build a resource-aware VM for a high-level language. I've figured out adequate solutions for most of the problems I've encountered, including separate heaps, quotas, etc. However, I'm not sure how I can account for a thread's stack space. Given a language process (LP) running in a heap with a

> The semantics around inlining alone are problematic enough to warrant serious hesitation. There are nicer ways to embed CPS call/return into LLVM; I just figured that there would not be much support for adding a new terminator because it would change a lot of code. Ideally we would have a block terminator like: cps call ghccc @bar (.. args ..) returnsto label %retpt Where the

Hi , As the subject, I'm using the CPS UPS. I use NUT to read the HID information. The device information is attached. After I read the information, I can't see the frequency information. I have used the CPS software to see the frequency information before. But I want to see the frequency in NUT by connecting CPS UPS. I have traced the NUT source code and find that the CPS HID table

Misha Brukman wrote: > >>1. Opcodes and intrinsics >> > That's not really correct. The intrinsics such as llvm.frameaddress and > llvm.returnaddress have no equivalents in LLVM opcodes -- the meaning of > the intrinsics is specifically machine-dependent, and LLVM (and its > opcodes) are machine-independent, so there is no valid interchange of > these intrinsics

(Sorry for the 2nd email Eli, I forgot to reply-all). > I'm not following how explicitly representing the return address of a call in the IR before isel actually solves any relevant issue. We already pass the return address implicitly as an argument to every call; you can retrieve it with llvm.returnaddress if you need it. Unfortunately the @llvm.returnaddress intrinsic does not solve

UPS - CYBERPOWER CPS DX600E upsc usb at localhost battery.charge: 100 battery.charge.low: 10 battery.charge.warning: 20 battery.mfr.date: CPS battery.runtime: 1650 battery.runtime.low: 300 battery.type: PbAcid battery.voltage: 4.8 battery.voltage.nominal: 12 device.mfr: CPS device.model: DX600E device.type: ups driver.name: usbhid-ups driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2

Summary ======= There is a need for dedicated continuation-passing style (CPS) calls in LLVM to support functional languages. Herein I describe the problem and propose a solution. Feedback and/or tips are greatly appreciated, as our goal is to implement these changes so they can be merged into LLVM trunk. Problem ======= Implementations of functional languages like Haskell and ML (e.g., GHC

[Apologies. This is a repost because the earlier post didn't have a subject heading and might have been missed by members] Hello, I wish to have lots of little stacks and be able to switch rapidly between them. I could do CPS transformation but don't like the overhead of creating gc'able continuation thunks and the copying from stack to heap. I'd like to explore a no-copy

Hi, Thanks for your guidance. I use Rad Hat. The explore-CPS.txt is attached. Thx. 2017-08-01 21:37 GMT+08:00 Charles Lepple <clepple at gmail.com>: > On Aug 1, 2017, at 5:47 AM, Andy Jan <andy1635qq at gmail.com> wrote: > > > > But I want to see the frequency in NUT by connecting CPS UPS. I have > traced the NUT source code and find that the CPS HID table

To this end, are there any implicit allocations being done by generated LLVM code, other than the system stack? Sandro On 6/18/07, Sandro Magi <naasking at gmail.com> wrote: > Given my recent posts, I think it's obvious that I'm trying to figure > out how to build a resource-aware VM for a high-level language. > > I've figured out adequate solutions for most of the

Hi, I made some debian packages related to icecast (libshout, ices,icecast,...). They are all available officialy, but tthey need to be validated to integrated official distribution (either Sid, or Etch). Feel free to try them out. Here is the lines you could add to you sources.list: deb ftp://infogerance.locataire-serveur.info/debian/ testing main deb-src

> Most architectures have a call instruction which does not push anything onto the stack; e.g. on ARM, the "BL" instruction saves the return address in LR. On other architectures, you can emulate this (for example, you could lower an IR "call" to LEA+JMP on x86-64). This is similar to what I was originally thinking, since the end goal of all of this is the following