search for: i48

Hi, LLVM only support primitive type i32 and i64, no i48. The clang translate "C int type" to i32 too. My question is if a cpu is 48 bits register size, how to write the backend for 48 bits register architecture. Can someone help me with this problem? Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: &lt...

On Sep 5, 2013, at 3:37 AM, gamma_chen <gamma_chen at yahoo.com.tw> wrote: > LLVM only support primitive type i32 and i64, no i48. The clang translate "C int type" to i32 too. My question is if a cpu is 48 bits register size, how to write the backend for 48 bits register architecture. Can someone help me with this problem? I'm not LLVM expert, but I'm pretty sure your initial sentence is false. For example...

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

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

>> 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) In the rema...

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 smallest legal ty...

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

...none (because bitwidth T is too big), look at all the legal types LT for which bitwidth T <= 4 * bitwidth of LT If there is one, take the smallest one (SLT) and promote T to 4*SLT. Continue with 8*, 16* etc. For example, if i24 and i32 are the legal types, with this algorithm types i33, ..., i48 would be promoted to i48 then expanded to two lots of i24. Types i49, ..., i64 would be promoted to i64 then expanded to two lots of i32. For example, if i10 and i32 are the legal types, i40 would be promoted to i64 then expanded to two lots of i32. Ciao, Duncan.

...uldn't figure out how to solve the following problem: I am trying to put a legend below two plots using the code below. The legend appears in the second plot, but I want the legend to appear below the two plots in the center of the total chart. At the moment the graphic looks like this: http://i48.tinypic.com/2h2fvhf.jpg [code] layout(matrix(1:2, nrow=1)) #c(down,left,top,right) par(mar=c(4,4,3,1)) plot(totalExp , totalDiffs, main="Years of experience", cex.main = 0.9, cex.lab=0.8, xlab="Years of experience", ylab="COCOMO II - expert estimate", pch=totalP...

...ve 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 taught things like this: i16 promotes to i24, i32 promotes to i48 which is then expanded to 2 x i24. Finally, all of the code would need to be audited to see if it assumes that types promoted to / expanded to (or from) are powers of two in length. Most of it probably doesn't assume any such thing, fortunately. Once types are legal, there's still the pr...

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

Hello, I have a suggestion to improve the Rails Lighthouse overview page. At present the description is very large. You need to scroll to find the tickets and more importantly the list of pages. I think a shorter description along the lines of http://i48.tinypic.com/2z6a7lt.png would be much better. All the information at present in the description can be moved into pages, and they can be linked appropriately. Either via a page or from the description. Also all the pages will be listed below the ticket bins making them accessible at one go. Cheers...

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

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

...:09 PM, Chris Lattner wrote: > > 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 (for example, a 24-bit DSP that I'd like to develop a > back end > > for has 24-, 48- a...

...run application HWA (normal works well). Frame is normal size, but game is squeezed and scrolling is failing, because it scrolls like hot spot would be something else. Screenshots: Sometimes frame looks like this: [Image: http://i49.tinypic.com/2u9pqm9.png ] Game area is squeezed: [Image: http://i48.tinypic.com/j80d9f.png ] Background is set to 640x480, but when I test game it's squeezed: [Image: http://i49.tinypic.com/6p5kcw.png ] I report this as a bug and I ask, is there any way to make it working fine? o.o

...1.i, 2.000000e+00 > %call16.i34.i = tail call float @llvm.exp.f32(float %tmp15.i33.i) nounwind > %tmp17.i35.i = fmul float %call16.i34.i, 0x3FD9884540000000 > %tmp19.i37.i = fmul float %tmp17.i35.i, %tmp7.i25.i > %tmp29.i47.i = fmul float %tmp7.i25.i, 0x3FF548CDE0000000 > %tmp30.i48.i = fadd float %tmp29.i47.i, 0xBFFD23DD40000000 > %tmp31.i49.i = fmul float %tmp7.i25.i, %tmp30.i48.i > %tmp32.i50.i = fadd float %tmp31.i49.i, 0x3FFC80EF00000000 > %tmp33.i51.i = fmul float %tmp7.i25.i, %tmp32.i50.i > %tmp34.i52.i = fadd float %tmp33.i51.i, 0xBFD6D1F0E0000000 >...

...2009 12:33 PM > To: llvmdev at cs.uiuc.edu > Subject: [LLVMdev] Adding multiples-of-8 integer types to MVT > > 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). B...

...mber 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 taught things like this: > i16 promotes to i24, i32 promotes to i48 which is then expanded to > 2 x i24.  Finally, all of the code would need to be audited to see > if it assumes that types promoted to / expanded to (or from) are > powers of two in length.  Most of it probably doesn't assume any > such thing, fortunately. > > Once types are le...