search for: stackifer

To get into more detail, I'm trying to update WebAssembly's `call` instruction. `call` is currently constrained to return one or zero arguments, so in TableGen we have a separate call Instruction for each possible return type. But I need to update calls to return arbitrarily many values of any combination of WebAssembly types, so even if we imposed some reasonable artificial limit like 8

On Sunday 22 February 2009 23:18:25 Chris Lattner wrote: > Have you seen: > http://llvm.org/docs/WritingAnLLVMBackend.html I have, and it's certainly helpful. Since the Kalescope tutorial is so amazingly easy to work through that it makes me jealous for a similar tutorial on the backend. But I'm definitely not complaining. =) > If you're targeting a stack machine, I'd

Hi Quentin, Thanks, that explanation makes sense. I can see that in a normal register machine, implicitly defs must be physical registers. In a stack machine like WebAssembly, though, implicit defs are known to be pushed onto the value stack just like any other defs. Slots on the value stack are represented by virtual registers until stackification, so for WebAssembly we do need the implicit defs

Can you elaborate on the fix you are thinking of? I'm not sure what you're thinking should change. On Tue, Nov 19, 2019 at 3:51 PM Quentin Colombet <qcolombet at apple.com> wrote: > It sounds to me that we should fix SDISel to accept both physical and > virtual definitions on variadic instructions. Though I wouldn’t bother > adding the support for implicit virtual

On Feb 22, 2009, at 5:43 PM, Wesley J. Landaker wrote: > > I would love to see a Kalescope-like tutorial that goes step-by-step > through > making a backend. At the very least, I'll be documenting my > adventure, so > maybe once I know what I'm doing I can turn it into a tutorial. Have you seen: http://llvm.org/docs/WritingAnLLVMBackend.html If you're targeting

...ke LLVM better by far in terms of the actual code and how it's put together, even if my understanding is very superficial. The advice I've gotten so far on this list is to use normal registers before register allocation and then switch to stack slots after register allocation much like x86 stackifer, using two sets of instructions. http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-November/018621.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-June/015430.html Work-in-progress git repository: http://repo.or.cz/w/llvm/zpu.git Some thoughts/problems: - In GCC I created registers which w...

> We mean ZPU looks like x86 fp stack. We handle it by register > allocating it like a normal register based cpu than add a x87 > stackifer pass to convert it to stack operations. Thanks! > You do not have to. Take a look at PPC and ARM branch fix up passes. > llvm backends compute exact length of instructions so it can determine > when it is necessary to convert a conditional branch to a conditional > branch of the oppos...

On Fri, 20 Jun 2008, [ISO-8859-1] ?yvind Harboe wrote: >> The ZPU has two instructions that I'd also like to use. These instructions >> can push a value from deeper down on the stack and also pop a value >> from the stack and store them deeper down on the stack. > > Sounds like the Intel X87 floating point stack, which we support. GCC does as well. Supporting floating

On Sunday 22 February 2009 17:06:06 Eli Friedman wrote: > On Sun, Feb 22, 2009 at 3:25 PM, Wesley J. Landaker <wjl at icecavern.net> wrote: > > * Has anyone else out there targeted (or tried to target) a stack > > machine before? Was it successfull? What problems did you have? > > Haven't done that, and I don't think there are any existing backends > like

Hi all, I need to figure out why InstrEmitter::EmitMachineNode assumes that when the number of outputs of a MachineSDNode is greater than the number of defs in the corresponding MCInstrDesc, the outputs in the difference will be placed into physical registers as opposed to virtual registers. The specific line in question is: bool HasPhysRegOuts = NumResults > NumDefs &&