similar to: [LLVMdev] how to define a 24-bits register class

On Nov 13, 2009, at 6:45 AM, ether zhhb wrote: > hi every one, > > i have a very strange cpu that have 24-bits reigsters, but i cant see > i24 in machine value type? and if defining it as MVT others will be > ok? You'd want to add a new i24 MVT enum. -Chris

Would there be any interest/opposition to extending the set of simple integer types in MVT to include the missing multiples of 8 (up to 64 bits)? That is: i24, i40, i48, i56? Adding the types to MVT (and ValueTypes.td) would allow LLVM to be targeted to architectures that have registers and operations of these sizes (for example, a 24-bit DSP that I'd like to develop a back end for has 24-,

Hi Ken, > Would there be any interest/opposition to extending the set of simple > integer types in MVT to include the missing multiples of 8 (up to 64 > bits)? That is: i24, i40, i48, i56? the type legalizer would need some work. Consider an architecture which has a 24 bit register. Then the type legalizer should legalize an i40 by first promoting it to an i48, then expanding that to

>> Would there be any interest/opposition to extending the set of simple >> integer types in MVT to include the missing multiples of 8 (up to 64 >> bits)? That is: i24, i40, i48, i56? By the way, the integer type legalization logic should probably go like this: let T be an integer type. (1) If T is legal, do nothing. (2) If there is a legal integer type which is bigger (in

Hi all, hope someone can help me out with this. Background Introduction I have a data set consisting of data collected from a questionnaire that I wish to validate. I have chosen to use confirmatory factor analysis to analyse this data set. Instrument The instrument consists of 11 subscales. There is a total of 68 items in the 11 subscales. Each item is scored on an integer scale between 1 to 4.

On Dec 2, 2009, at 12:32 PM, Ken Dyck wrote: > Would there be any interest/opposition to extending the set of simple > integer types in MVT to include the missing multiples of 8 (up to 64 > bits)? That is: i24, i40, i48, i56? > > Adding the types to MVT (and ValueTypes.td) would allow LLVM to be > targeted to architectures that have registers and operations of these > sizes

On Saturday, December 05, 2009 7:34 AM, Duncan Sands wrote, > > >> Would there be any interest/opposition to extending the > set of simple > >> integer types in MVT to include the missing multiples of 8 > (up to 64 > >> bits)? That is: i24, i40, i48, i56? > > By the way, the integer type legalization logic should > probably go like > this: let

Grr... ---------- Forwarded message ---------- From: OvermindDL1 <overminddl1 at gmail.com> Date: Sat, Dec 5, 2009 at 5:58 PM Subject: Re: [LLVMdev] Adding multiples-of-8 integer types to MVT To: Duncan Sands <duncan.sands at math.u-psud.fr> On Sat, Dec 5, 2009 at 5:33 AM, Duncan Sands <duncan.sands at math.u-psud.fr> wrote: >>> Would there be any interest/opposition

Hi, > I am not sure how legalizer and friends deal with i24 / f24 as legal > types. the type legalizer currently assumes that all legal integer types have a power-of-two number of bits. I don't see any obstacles to making it more general though. First off, i24 would need to be added to the list of simple value types. Then the integer promotion and expansion logic would need to be

Hello everybody, I have stumbled upon a test case (the attached module is a slightly reduced version) that shows extremely reduced performance on linux compared to windows when executed using LLVM's JIT. We narrowed the problem down to the actual code being generated, the source IR on both systems is the same. Try compiling the attached module: llc -O3 -filetype=asm -o BAD.s BAD.ll Under

On Nov 22, 2008, at 7:48 AM, Wei wrote: > Do you mean MVT::getIntegerVT? Because I can not find > getExtendedIntegerVT in the llvm source codes. > I am excited seeing this function, however I have the following more > questions. See ValueTypes.h and ValueTypes.cpp. Also this example: @str = internal constant [4 x i8] c"%d\0A\00" define void @foo2(i24 %a, i24 %b) nounwind

O...k... I try to make some conclusions: 1) The conversion from f32 to f24 or i32 to i24 should be written in the backend. Because we should not put any hardware dependent behaviors in the frontend. If we may change our H/W platform to another one which supports f32, i32 natively, we will only need to change the backend codes. For example: The backend approach means that integer division is a

Do you mean MVT::getIntegerVT? Because I can not find getExtendedIntegerVT in the llvm source codes. I am excited seeing this function, however I have the following more questions. 1) You mention I will have to change not small amount of target indenpendent codegen codes to support this extended type. Are there any document to describe how to do such kind modification? I see there is a

> I disagree. This should be handled by the type legalization > infrastructure. huh... As far as I know, the type legalization is in the SelectionDAG phase, and it is also in the backend. Am I right? or I miss something. > there is currently no support for anything like f32 -> f24 You say "there is currently no support for anything like f32 -> f24", does it means I can

I think Duncan and I disagree. Generally I would defer to anybody else on this list: my experience is backend Target only, with very little poking around the internals. I'm usually asking, not answering, questions here: the 24 bit floats reminded me of the "good old days" at ATI. That said, I think you could make f32/i32 work for your purposes - given the limited types

Hi, I am writing a backend and having issues with properly lowering the result of getElementPtr ( specifically the add node that it generates). If we take this IR: %struct.rectangle = type { i24, i24 } ; Function Attrs: nounwind readonly define i24 @area(%struct.rectangle* nocapture readonly %r) #0 { entry: %width = getelementptr inbounds %struct.rectangle* %r, i16 0, i32 0 %0 = load i24*

Below is attached a full IR module that can reproduce this issue, but the part to notice is this: %Foo96Bits = type <{ i24, i24, i24, i24 }> define internal fastcc i16 @main.0.1() unnamed_addr #2 !dbg !113 { Entry: %value = alloca %Foo96Bits, align 1 %b = alloca i24, align 4 %0 = bitcast %Foo96Bits* %value to i8*, !dbg !129 call void @llvm.memcpy.p0i8.p0i8.i64(i8* %0, i8* bitcast

On Wednesday 26 November 2008 09:31:26 Wei wrote: > O...k... I try to make some conclusions: > > 1) The conversion from f32 to f24 or i32 to i24 should be written in > the backend. I disagree. This should be handled by the type legalization infrastructure. After all, that's what it is for! However there is currently no support for anything like f32 -> f24. On the other

Hi Steve, Thanks for the tip regarding MIOperandInfo, I didn't think of that part of the tablegen description. Sadly, I did actually mean: r1 = *(i0 += m0). So increment i0 by m0. Read memory the memory location "pointed" to by i0. Store in r1. Sadly I am not too familiar with compiler terminology, so I don't know if there is a proper term for such a load. On Thu, Oct 23,

----- Original Message ----- > From: "Bruce Hoult" <bruce at hoult.org> > To: "Johnny Val" <johnnydval at gmail.com> > Cc: "<llvmdev at cs.uiuc.edu>" <llvmdev at cs.uiuc.edu> > Sent: Thursday, October 23, 2014 8:31:35 AM > Subject: Re: [LLVMdev] Question regarding getElementPtr/Addressing modes in backend > > Many CPU