search for: i24

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 hand, as I mentioned in another email, I think i32 -> i...

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

...onDAG 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 not write codes like below? addRegisterClass(MVT::i24, XXXRegisterClass); If the target-indenpendent codegen supports i24, then I can writes codes like above, then does it means LLVM backend codegen can handle any i32->i24 and f32->f24 for me automatically? So that I don't need to worry about i32->i24 and f32->f24? > On the other...

...said, I think you could make f32/i32 work for your purposes - given the limited types and memory operations of unextended GLSL. At a minimum, I think that starting with f32/i32 would give you chance to learn and understand more about LLVM. If there are people who are willing to help you add i24/f24 to LLVM's core code base or you have time to learn about LLVM's internals on your own, then adding 24 bit support seems the safer path (if only because it is recommended by people more knowledgeable than myself). Dan On Nov 26, 2008, at 4:38 AM, Wei wrote: >> I disagree....

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* %width, align 4, !tbaa !1 %height = getelementptr inbounds %struct.rectangle* %r, i16 0, i32 1...

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 (%Foo96Bits* @4 to i8*), i6...

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

...dval at gmail.com> wrote: > > > 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* %width, align 4, !tbaa !1 > > %he...

...t; > > > > 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* %width, align 4, !tbaa !1 > > %heig...

...? 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 { entry: %t1 = add i24 %a, %b %t2 = zext i24 %t1 to i32 %t3 = tail call i32 (i8*, ...)* @printf( i8* getelementptr ([4 x i8]* @str, i32 0, i32 0), i32 %t2 ) nounwind ret void } declare i32 @printf(i8*, ...) nounwind You can run llc on it to see how codegen deals wit...

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 two lots of i24. Another issue is how vectors of i24 would be represented in memo...

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? thank you very much

...ion. I think I am pretty new in LLVM world. wanna to get more help from you expert. Thx. Wei. On Nov 21, 3:54 pm, Evan Cheng <ech... at apple.com> wrote: > 24 bit is not unusual in the DSP world. I suppose int == 24 bit   > integer for some of these chips? > > There isn't a i24 simple type. However, you can create an extended   > integer type. See getExtendedIntegerVT. It's almost guaranteed you   > will have to change a chunk of target independent codegen to support   > the use of an extended type though. > > Evan > > On Nov 20, 2008, at 4:46 AM,...

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-, 48- and 56-bit native integer types). Back ends are current...

...d expert, (although maybe I'll need to be soon!), so I won't look at the patches right now, however may at some stage in the future myself or colleague may request these patches from yourself. Yes, our 24-bit architectures have non-power-of-2 register sizes. When you mentioned addition of i24 - would that facilitate this architecture to claim that it's bytes are 24-bits in size? (Sorry for being vague, but I'm a debugger person currently...) thanks again for your help, Matt On Tue, 2014-09-09 at 18:55 +0000, Patrik Hägglund H wrote: > Hi Matt, > > We maintain a se...

>> 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 bitwidth) than T, then promote T to the smallest legal type which is bigger than T. (3) I...

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 T be an integer type. > > (1) If T is legal, do nothing. > (2) If there is a legal integer type which is bigger (in > bitwidth) than T, then promote T to the smalles...

Hi everyone! Here, I have a question and am curious about i128. I want to know how the LLVM handle i128, because many compiler backend doesn't support i128 directly. So I am very curious and want to how the llvm handle this situation? Besides i128, such as i256, i512, even i24? Thanks. Best Regards Wu Zhao -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150202/74395a81/attachment.html>

...w tricky this would be. Matt On Tue, 9 Sep 2014 11:49:01 +0100 Johnny Val <johnnydval at gmail.com> wrote: > Hi Matthew, > > The byte==8 bits is more of a Clang issue rather than an LLVM issue. I > believe your bigger issue will be the fact that you would need to make > i24's a legal type in your backend, which as far as I know (unless > something has changed recently), is a _big_ job. I briefly looked > into it at one point, and decided to leave it for another day. > > I am also unsure how hard byte=8bits is backed into Clang. You might > want to...