similar to: [LLVMdev] Recent changes to MCRegisterClass fields: uint8_t is too narrow

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

Our architecture(TCE) can have LOTS of registers. It seems r152019 changed some register bookkeeping data structures to 8-bit. This broke support for architectures with >255 registers. Please revert this change or make those register-related values at least 16 bits wide.

On Mar 5, 2012, at 5:39 AM, Heikki Kultala wrote: > Our architecture(TCE) can have LOTS of registers. > > It seems r152019 changed some register bookkeeping data structures to > 8-bit. This broke support for architectures with >255 registers. > > Please revert this change or make those register-related values at least > 16 bits wide. I agree. We can limit the number

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

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 example to load 8/16-bit values into 32-bit registers (with sign or zero extension). Any optimizations performed during codegen will be in this

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

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

We observed exact same problem, and I did put in place a mechanism to recognize and break such false dependencies right before pre-RA scheduler (in DAG->DAG lowering), but the immediate observed effect for our back end was performance reduction, since none of the current schedulers were capable of dealing with newly presented parallelism in BB (resulted in high reg pressure and

Hi Craig, I updated from the trunk some minutes ago, and thus got the "explicit". PrintReg constructor. When I do not include raw_ostream.h after including Debug.h in the backend cpp files, I now get compilation errors, not only when trying to print floats but also in other places. For example, for the code bool ADRESRegisterInfo::hasReservedCallFrame(const MachineFunction &MF)

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 example to load 8/16-bit

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

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

Looking around today, it appears that TargetRegisterClass and MCRegisterClass only includes a single alignment. This is documented as being the minimum legal alignment, but it appears to often be greater than this in practice. For instance, on x86 the alignment of %ymm0 is listed as 32, not 1. Does anyone know why this is? Additionally, where are these alignments actually defined? I

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

On 08/31/2015 03:59 PM, Matthias Braun wrote: > Looks to me like the alignment is specified in tablegen. From Target.td: > > class RegisterClass<string namespace, list<ValueType> regTypes, int alignment, > dag regList, RegAltNameIndex idx = NoRegAltName> > > X86RegisterInfo.td: > > def VR256 : RegisterClass<"X86", [v32i8,

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

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 example to load 8/16-bit values into 32-bit registers (with sign or zero extension). Any optimizations performed during codegen will be in this representation, or even MachineInstr form, which is post-isel and any sign-extension information

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

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