search for: stackifi

...Live Interval Analysis -- Natural Loop Construction -- Live Variable Analysis -- Eliminate PHI nodes for register allocation -- Two-Address instruction pass Linear Scan Register Allocator -- Live Interval Analysis -- Linear Scan Register Allocator Live Variable Analysis X86 FP Stackifier -- Live Variable Analysis -- X86 FP Stackifier Prolog/Epilog Insertion & Frame Finalization -- Prolog/Epilog Insertion & Frame Finalization X86 Peephole Optimizer -- X86 Peephole Optimizer X86 AT&T-Style Assembly Printer -- X86 AT&T-Style Assembly Printer Mach...

...l Loop Construction > -- Live Variable Analysis > -- Eliminate PHI nodes for register allocation > -- Two-Address instruction pass > Linear Scan Register Allocator > -- Live Interval Analysis > -- Linear Scan Register Allocator > Live Variable Analysis > X86 FP Stackifier > -- Live Variable Analysis > -- X86 FP Stackifier > Prolog/Epilog Insertion & Frame Finalization > -- Prolog/Epilog Insertion & Frame Finalization > X86 Peephole Optimizer > -- X86 Peephole Optimizer > X86 AT&T-Style Assembly Printer > -- X86 AT&...

...ariable Analysis > > -- Eliminate PHI nodes for register allocation > > -- Two-Address instruction pass > > Linear Scan Register Allocator > > -- Live Interval Analysis > > -- Linear Scan Register Allocator > > Live Variable Analysis > > X86 FP Stackifier > > -- Live Variable Analysis > > -- X86 FP Stackifier > > Prolog/Epilog Insertion & Frame Finalization > > -- Prolog/Epilog Insertion & Frame Finalization > > X86 Peephole Optimizer > > -- X86 Peephole Optimizer > > X86 AT&T-Styl...

.... Register allocation via coloring of chordal graphs. -- Register allocation via coloring of chordal graphs. -- Virtual to def/use mapping - Fernando. -- Edge liveness analyses - Fernando. ***************************************************************** Live Variable Analysis X86 FP Stackifier -- X86 FP Stackifier -- Live Variable Analysis Prolog/Epilog Insertion & Frame Finalization -- Prolog/Epilog Insertion & Frame Finalization X86 AT&T-Style Assembly Printer -- X86 AT&T-Style Assembly Printer Machine Code Deleter -- Machine Code Deleter Could some...

...a coloring of chordal graphs. > -- Register allocation via coloring of chordal graphs. > -- Virtual to def/use mapping - Fernando. > -- Edge liveness analyses - Fernando. > ***************************************************************** > Live Variable Analysis > X86 FP Stackifier > -- X86 FP Stackifier > -- Live Variable Analysis > Prolog/Epilog Insertion & Frame Finalization > -- Prolog/Epilog Insertion & Frame Finalization > X86 AT&T-Style Assembly Printer > -- X86 AT&T-Style Assembly Printer > Machine Code Deleter >...

Hi all, we're looking around a bit for a small and simple stack-based architecture, that we could use as a sidekick to the DSP processor we are developing. We've been looking at ZPU for a bit, but are also considering developing our own hardware for this (possibly very much tuned to LLVM). Of course, that would also mean building an LLVM backend. I guess having a very simple backend

...g 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 a stack machine, I'd strongly recommend not using the llvm register allocators and just run you own custom stackifier pass instead. -Chris

In the X86RegisterInfo.td file, RST is defined like this: // Floating point stack registers (these are not allocatable by the // register allocator - the floating point stackifier is responsible // for transforming FPn allocations to STn registers) def RST : RegisterClass<"X86", [f64], 32, [ST0, ST1, ST2, ST3, ST4, ST5, ST6, ST7]> { let MethodProtos = [{ iterator allocation_order_end(const MachineFunction &MF) const;...

Hi all, I was asked to write a C compiler back end for a dated stack based architecture, i.e. once whose instructions operate only on the top elements of a stack and doesn't use arguments, something like the JVM. I looked at some open source compilers (gcc, sdcc, tinyc and LLVM). To me LLVM seems promising (and I likes C++). Because I'm new here I need your help to understand if: 1)

...> > -- Register allocation via coloring of chordal graphs. > > -- Virtual to def/use mapping - Fernando. > > -- Edge liveness analyses - Fernando. > > ***************************************************************** > > Live Variable Analysis > > X86 FP Stackifier > > -- X86 FP Stackifier > > -- Live Variable Analysis > > Prolog/Epilog Insertion & Frame Finalization > > -- Prolog/Epilog Insertion & Frame Finalization > > X86 AT&T-Style Assembly Printer > > -- X86 AT&T-Style Assembly Printer >...

On Tue, 2005-07-26 at 17:25 -0700, Michael McCracken wrote: > Since I'm modifying llc, I have a couple small questions about that code: > > opt and analyze (and a couple of other places) add a verifier pass, > but llc doesn't. > This would seem to make sense for llc as well - should I add it, with > the corresponding > hidden -no-verify option? I can't see any

...utorial 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 strongly recommend not using > the llvm register allocators and just run you own custom stackifier > pass instead. After reading <http://www.llvm.org/docs/CodeGenerator.html#regAlloc_ssaDecon> is correct to say that if I don't use an existing LLVM register allocation pass, that I would need to do my stackification directly on the SSA form? Could/should I still reuse parts l...

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

...5c4d __libc_start_main + 253 17 llc 0x0000000000517ac9 Stack dump: 0. Program arguments: /local/pcheng/tmp/llvm_build/bin/llc -mcpu=i386 -march=x86-64 -mattr=-sse2 test.ll -o test.bc 1. Running pass 'Function Pass Manager' on module 'test.ll'. 2. Running pass 'X86 FP Stackifier' on function '@f3' Abort -------- ir --------- ; ModuleID = 'module_name' declare void @llvm.memcpy.p0i8.p0i8.i64(i8* nocapture, i8* nocapture, i64, i32, i1) nounwind define void @f3(double %a, [2 x double]*) { entry: %r1 = alloca [2 x double] br label %1 ; <label&...

On 7/25/05, Reid Spencer <reid at x10sys.com> wrote: > On Mon, 2005-07-25 at 21:48 -0700, Michael McCracken wrote: > > On 7/25/05, Reid Spencer <reid at x10sys.com> wrote: > > > Why not just create your pass as a shared object and: > > > > > > opt -load mypass.so -mypass | llc > > > > My pass is an implementation of an analysis group that

On Nov 19, 2009, at 5:28 PM, Jon Harrop wrote: > > Are these barfs due to bugs in my generated code or is this parts of LLVM not > honoring tail calls? It was a bug in LLVM, with emitting tail calls at -O0. It's now fixed, as of r89444. Dan

...ndleSpecialFP(llvm::ilist_iterator<llvm::MachineInstr>&): Assertion `StackTop == 0 && "Stack should be empty after a call!"' failed. 0 llc 0x08b8efe8 Stack dump: 0. Program arguments: llc --regalloc=simple -f aout.bc -o aout.s 1. Running pass 'X86 FP Stackifier' on function '@gc' Aborted -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e

...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 were just stack slots in the stack frame. This allowed the reload and register allocation to do it's thing. What kind pre-stackifier register file do I define for the ZPU? - In GCC I wrote a piece of C that recursively unrolled intermediate representation to machine code instructions. So any treedepth was fine as long as it consisted of operations that were supported by the instruction set. I'm can't get a handle on h...

...Subject:Re: [LLVMdev] Writing a backend for the ZPU > > > Hello, Some > thoughts/problems: - In GCC I created > registers which were just stack > slots in the stack frame. This > allowed the reload and register allocation > to do it's thing. What > kind pre-stackifier register file do I define for > the ZPU? - > In GCC I wrote a piece of C that recursively > unrolled intermediate > representation to machine code instructions. So any > treedepth was > fine as long as it consisted of operations that were supported > by > the inst...

...mp;MF), but there is no > API like registerOpt. what does it mean? Thanks MachineFunctionPass instances are part of the code generator. As such, they are not supposed to modify the LLVM code and their output does not go to bytecode. You *can* write target specific (e.g. the X86 floating point stackifier pass) or target independent passes (e.g. the register allocators) with MachineFunctionPass's, but I don't think this is what you really want to do. > For MachineFunction pass, the doc says it is not allowed to do any of the following: MachineFunctionPass's are even more restricte...