search for: desutter

Hi all, in r152019 (from ctopper), the number of available registers of any type in a machine description is decreased to 256 because it needs to be encoded in uint8_t now. I'm trying to support an experimental embedded architecture with more registers (out of tree), but now that becomes impossible. Anyone knows a solution? Thanks, Bjorn De Sutter Computer Systems Lab Ghent University

I changed it to uint16_t in r152100. Is that enough for your architecture? On Tue, Mar 6, 2012 at 12:24 AM, Bjorn De Sutter < bjorn.desutter at elis.ugent.be> wrote: > Hi all, > > in r152019 (from ctopper), the number of available registers of any type > in a machine description is decreased to 256 because it needs to be encoded > in uint8_t now. I'm trying to support an experimental embedded architecture > wit...

On Jan 21, 2013, at 6:34 AM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > > On Mon, Jan 21, 2013 at 9:16 AM, Bjorn De Sutter <bjorn.desutter at elis.ugent.be> wrote: > On 21 Jan 2013, at 14:39, Justin Holewinski <justin.holewinski at gmail.com> wrote: > >> Instruction selection happens on a different IR: SelectionDAG. In this IR, there are sign-extending loads that the IR converter will use, and are used for examp...

On Mon, Jan 21, 2013 at 9:16 AM, Bjorn De Sutter < bjorn.desutter at elis.ugent.be> wrote: > On 21 Jan 2013, at 14:39, Justin Holewinski <justin.holewinski at gmail.com> > wrote: > > Instruction selection happens on a different IR: SelectionDAG. In this > IR, there are sign-extending loads that the IR converter will use, and are > use...

...at mean that during instruction selection, I have to start looking for patterns like select (cmp gt src1 src2) (copy src1) (copy src2) to find opportunities for max/min operations? Or should that not be needed? Thanks. Bjorn > > On Mon, Jan 21, 2013 at 5:32 AM, Bjorn De Sutter <bjorn.desutter at elis.ugent.be> wrote: > Hi all, > > when compiling code like > > short ptr * = some_address; > int val; > > val = *ptr; > if (val>2047) > val = 2047; > else if (val<-2048) > val = -2048. > // other things done that require val to be an int...

.... What is your timeline? How much time you can afford until you must have this? Also, are you attending the LLVM meeting in San Jose this week? Sergei Larin -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. -----Original Message----- From: Bjorn De Sutter [mailto:bjorn.desutter at elis.ugent.be] Sent: Monday, November 14, 2011 10:18 AM To: Sergei Larin Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] alias analysis in ScheduleDagInstr class Hi Sergei, thanks for considering my question. We if-convert some code, such that the basic block looks as follows after if-conver...

....com> wrote: > Can you try making the constructor "explicit" for PrintReg in include/llvm/Target/TargetRegisterInfo.h. I think you were getting an implicit conversion there which should probably be fixed anyway. > > On Mon, Nov 26, 2012 at 11:47 PM, Bjorn De Sutter <bjorn.desutter at elis.ugent.be> wrote: > Hi, > > that solved my problem on trunk as well, thanks. Strange that you have to include this though. > > Bjorn > > On 27 Nov 2012, at 00:00, Daniel Prokesch <daniel.prokesch at gmail.com> wrote: > > > Hi, > > > > I...

Hi Sergei, thanks for considering my question. We if-convert some code, such that the basic block looks as follows after if-conversion: ld char from A into R1 p1 = R1>255? (generate the predicate) p1 | R1 = 255 (conditional execution) st char R1 to A ld char from A+1 into R2 p2 = R2>255? (generate the predicate) p2 | R2 = 255 (conditional execution) store char R2 to A+1 The problem is

Can you try making the constructor "explicit" for PrintReg in include/llvm/Target/TargetRegisterInfo.h. I think you were getting an implicit conversion there which should probably be fixed anyway. On Mon, Nov 26, 2012 at 11:47 PM, Bjorn De Sutter < bjorn.desutter at elis.ugent.be> wrote: > Hi, > > that solved my problem on trunk as well, thanks. Strange that you have to > include this though. > > Bjorn > > On 27 Nov 2012, at 00:00, Daniel Prokesch <daniel.prokesch at gmail.com> > wrote: > > > Hi, > > >...

...load? This seems like it would only generate ambiguity. Generally, we don't extend the core IR if something is already expressible. For what it's worth, the max detection could fairly easily be done in a back-end isel pattern. On Mon, Jan 21, 2013 at 5:32 AM, Bjorn De Sutter < bjorn.desutter at elis.ugent.be> wrote: > Hi all, > > when compiling code like > > short ptr * = some_address; > int val; > > val = *ptr; > if (val>2047) > val = 2047; > else if (val<-2048) > val = -2048. > // other things done that require val to be an int ....

done, bug 15057, hope I submitted it correctly ... On 23 Jan 2013, at 22:29, Arnold Schwaighofer <aschwaighofer at apple.com> wrote: > Hi Bjorn, > > could you file a bug on llvm.org/bugs and cc me on it. > > Thanks, > Arnold > > >> So it appears that also the ARM backend has a big problems with sign-extending loads. >> >> I've compiled the

Hi, that solved my problem on trunk as well, thanks. Strange that you have to include this though. Bjorn On 27 Nov 2012, at 00:00, Daniel Prokesch <daniel.prokesch at gmail.com> wrote: > Hi, > > I accidentally stumbled upon your post. > I observed similar behaviour whenever I did not include > > #include "llvm/Support/Debug.h" > #include

Hi Bjorn, could you file a bug on llvm.org/bugs and cc me on it. Thanks, Arnold > So it appears that also the ARM backend has a big problems with sign-extending loads. > > I've compiled the following loop > > short in[]; > int out[]; > int value; > > for (i = 0; i < nr; i++) { > value = in[i]; > if (value>2047) >

Hi all, when compiling code like short ptr * = some_address; int val; val = *ptr; if (val>2047) val = 2047; else if (val<-2048) val = -2048. // other things done that require val to be an int ... The load operation is represented by a load and a sign extension operation in the LLVM IR. On most target architectures, there exist signed halfword load instructions, so the load and

----- Original Message ----- > From: "Bjorn De Sutter" <bjorn.desutter at elis.ugent.be> > To: llvmdev at cs.uiuc.edu > Sent: Tuesday, November 27, 2012 6:49:39 AM > Subject: Re: [LLVMdev] loop pragmas > > I am thinking about another use of annotations that fits in a longer > term vision, which centers around feeding compilers with information &g...

On Sep 18, 2012, at 1:45 PM, Bjorn De Sutter <bjorn.desutter at elis.ugent.be> wrote: > I am working on a backend for a CGRA architecture with advanced predicate support (as on EPIC machines and as first used in the OpenIMPACT compiler). Until last month, the backend was working fine, but since the r161643 commit by stoklund, my backend doesn't wo...

Hi, I am working on a backend for a CGRA architecture with advanced predicate support (as on EPIC machines and as first used in the OpenIMPACT compiler). Until last month, the backend was working fine, but since the r161643 commit by stoklund, my backend doesn't work anymore. I think I noticed some related commits later on, and the assertion I get on the latest trunk (r164162) differs from

I am thinking about another use of annotations that fits in a longer term vision, which centers around feeding compilers with information from higher-level tools such as precompilers. Deciding how to map a portable piece of software to a heterogeneous multicore processor and get the best performance for a range of widely varying architectures, requires much higher level code analysis than what is

Hi all, I am working on a CGRA backend (something like a 2D VLIW), and we also absolutely need predication. I extended the IfConversion pass to allow it to be executed multiple times and to predicate already predicated code. This is necessary to predicate code with nested conditional statements. At this point, we support or, and, and conditional predicates (see Scott Mahlke's papers on this

On 11/21/2012 11:32 AM, Tobias Grosser wrote: > On 11/21/2012 03:45 PM, Krzysztof Parzyszek wrote: >> >> I'm thinking of this in terms of parallelization directives. The >> optimizations that rely on such annotations would need to be done as >> early as possible, before any optimization that could invalidate them. >> If the annotation can become false, you are