similar to: [LLVMdev] Supporting pre-allocated registers in LLVM

Hi there i would like to ask a few questions to the developers responsible for the register allocator(s) design in LLVM (Fernando and other people). First of all, congrats on providing more than one option for register allocation. Now to the questions: 1. I can see the standard algorithms (bigblock, linearscan -- good choice for the JIT and for general use as well, and the other algorithms).

Quoting Bill Wendling <isanbard at gmail.com>: > Hi Nikolaos, > > I have an alpha version of Chow & Hennesey's priority-based graph > coloring algorithm. It's suffering from some bit-rotting -- e.g., > there's some trouble with how it calculates "forbidden" registers. > You're welcome to the code, if you'd like to hack on it. I've been

>> You mean a temporary defined in an instruction. OK, that is what i >> basically >> need here. Is it guaranteed to "live" in the physical register for >> the entire >> program (or at least for a single function, which would trivially >> work for >> single-function programs)? >No it's just guaranteed to be defined in a fixed register.

> > You are thinking about the gcc extension which allows the programer > to tie a register to global variable? This feature isn't implemented > nor am I aware of anyone driving to get it to implemented. Looks like > you will have to roll up your sleeves if that's what you want. :-) > > Evan Hi Evan is this the -fixed-reg<num> feature, or something that has

Hi everyone, Quick summary: LLVM now has a new register allocator particularly suitable for compiling (very) large, machine-generated functions. Longer story: I've recently been using LLVM in an application that involves JITing fairly large functions that have no control flow - they're just flat sequences of instructions, anywhere from 100 to 10000+ in size. (The control flow is

On Oct 4, 2007, at 10:40 PM, nkavv at physics.auth.gr wrote: > 2. Which are the new register allocation algorithms currently under > design? Do > they support preallocation of registers (it is different to > "fixing" a register > in GCC parlance)? > Hi Nikolaos, I have an alpha version of Chow & Hennesey's priority-based graph coloring algorithm.

On Oct 6, 2007, at 6:11 PM, nkavv at physics.auth.gr wrote: >>> You mean a temporary defined in an instruction. OK, that is what i >>> basically >>> need here. Is it guaranteed to "live" in the physical register for >>> the entire >>> program (or at least for a single function, which would trivially >>> work for >>>

Hi Duraid, > Hi everyone, > > Quick summary: > > LLVM now has a new register allocator particularly suitable for > compiling (very) large, machine-generated functions. Congrats! Very good job! > Longer story: > > I've recently been using LLVM in an application that involves JITing > > fairly large functions that have no control flow - they're

Hi Duncan >> br i1 %38, label %17, label %39 >> ; <label>:39 ; preds = %._crit_edge >> ret void >> >> However, ";" is a comment-line character. How is this interpreted, as a >> meta-comment? (a semantically important comment)? > > it's just a comment and has no semantic comment. You can delete

Hi Justin, >> Has anyone had similar problems with the NVPTX backend? Shouldn't this >> code be linked to the AsmPrinter library for NVPTX (already)? > > What do you mean by "doesn't work"? The AsmPrinter library really houses > the MCInst printer, which isn't implemented for NVPTX yet. The older > assembly printer works just fine. This is

Hi Duncan >>> br i1 %38, label %17, label %39 >>> ; <label>:39 ; preds = %._crit_edge >>> ret void >>> >>> However, ";" is a comment-line character. How is this interpreted, as a >>> meta-comment? (a semantically important comment)? >> >> it's just a comment and has no

Hi, > Can you post the llc command line you're using? Can you post an LLVM IR > file that causes this behavior? yes: ${LLVM_PATH}/bin/llc -o helloworld.s -march=nvptx helloworld.ll where LLVM_PATH my local installation path for LLVM. Also attaching helloworld.c: #include <stdio.h> int main(void) { printf("Hello World!\n"); return 0; } and helloworld.ll:

Hi Nikolaos, Following commands work great for me. $ clang -S -emit-llvm -target nvptx -x cl -include clc/clctypes.h ../data-types/scalar.cl $ llc -mcpu=sm_30 scalar.s You can follow Justin's blog [1]. It helped me a lot to understand where to start. [1] http://jholewinski.org/blog/llvm-3-0-ptx-backend/ Best, Ankur On Mon, Feb 4, 2013 at 11:40 PM, Justin Holewinski < justin.holewinski

On Mon, Feb 4, 2013 at 1:09 PM, <nkavv at physics.auth.gr> wrote: > Hi Justin, > > > Has anyone had similar problems with the NVPTX backend? Shouldn't this >>> code be linked to the AsmPrinter library for NVPTX (already)? >>> >> >> What do you mean by "doesn't work"? The AsmPrinter library really houses >> the MCInst

Alright, couple of points here: 1. Address space 0 is invalid for global variables. This is causing a crash in llc where we use llvm_unreachable() on this case. This is most likely why you're seeing llc run forever. The fix for this is to use address space 1 for globals, which puts them into PTX global memory. On our side, we should provide a meaningful error message in this case. 2. The

Hi all, i'm writing a TXL (http://www.txl.ca) grammar and a revamp of bison/flex grammar for LLVM. I've noticed an inconsistency regarding label naming conventions. For instance, the following is a segment of legit LLVM assembly (human-readable) IR: br i1 %38, label %17, label %39 ; <label>:39 ; preds = %._crit_edge ret void

Hi all, I'm trying to use the newly added (in LLVM 3.2) NVPTX backend for producing PTX (Parallel Thread eXecution) assembly from simple C programs. While using llc with -march for mips and x86 works, -march=nvptx doesn't work. This seems reasonable since I can see that the libLLVMNVPTXAsmPrinter.a library is about 500 bytes (thus empty). However, the strange thing is that

Hi Roman, > True. I'm working on the version of the linear scan based on Wimmer's > thesis. It supports live range splitting. I'd like to compare it with > yours. Do you have any good examples of those fairly large functions > that are just flat sequences of instructions, anywhere from 100 to > 10000+ in size??? You can find a couple attached to bug #1512, but I'm

Hi all, i'm just starting out with LLVM (although i've been observing its evolution since that first release some years ago :) I would like to develop a backend for a generic assembly-like language, called NAC (N-Address Code). More info on NAC can be found here: http://www.nkavvadias.com/hercules/nac-refman.html (HTML) http://www.nkavvadias.com/hercules/nac-refman.pdf (PDF) You

> From: "Wilfred L. Guerin" <wilfredguerin at gmail.com> > Subject: [LLVMdev] LLVM Expansions > > It is very relevant that LLVM look into handeling HDL and other binary > and analogue operation modeling capbilities, as well as expand this what is binary? you mean digital right? > Without confirming the true characteristics of the lower structure > types and