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

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 >>>

> > 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 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).

> > 1. I can see the standard algorithms (bigblock, linearscan -- good > > choice for > > the JIT and for general use as well, and the other algorithms). Is > > it possible > > to pre-allocate registers in your linearscan (or in another > > allocation engine) > > for specific source-level or (better) intermediate code (bitcode) > > level > >

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

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.

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 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

On Thu, Jan 24, 2013 at 7:20 AM, Ahmed Bougacha <ahmed.bougacha at gmail.com>wrote: > On Thu, Jan 24, 2013 at 12:46 PM, <nkavv at physics.auth.gr> wrote: > > 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

On Thu, Jan 24, 2013 at 12:46 PM, <nkavv at physics.auth.gr> wrote: > 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: >

Hi all is it possible to avoid the emission of metadata information by opt and/or clang? For instance, I would like to go without "tbaa" metadata in LLVM assembly code as printed by "-emit-llvm". I'm using the 3.1 binary release for MinGW (and for Linux on a different machine). Best regards Nikolaos Kavvadias