search for: baldr

...other hand, as I mentioned in another email, I think > i32 -> i24 can be done generically. I don't think I got you here... You mean using the legalizer to handle this for me? or modify the target independent codegen to let it know i24? Thanks. Wei. On Nov 26, 5:07 pm, Duncan Sands <baldr... at free.fr> wrote: > 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 typ...

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

...I think >> i32 -> i24 can be done generically. > > I don't think I got you here... > You mean using the legalizer to handle this for me? or modify the > target independent codegen to let it know i24? > > Thanks. > Wei. > > On Nov 26, 5:07 pm, Duncan Sands <baldr... at free.fr> wrote: >> 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...

Hi Stephan, > I'm trying to figure out why the following sequence of intructions is > not collapsed to "ret i32 0" by the opt tool with "-03". no target data maybe? Ciao, Duncan.

Hi, > > I think he means the lines like: > > > > switch (Opcode) { > > > > default: assert(0 && "Unknown load!"); > > > > > > where the default case is never executed. > > > I would personally appreciate expected to fail tests that ensure the > assertions actually catch the bad inputs that they were designed to

Hi, I'm trying to figure out why the following sequence of intructions is not collapsed to "ret i32 0" by the opt tool with "-03". --- %0 = type <{ i32* }> define i32 @main(%0* noalias nocapture %arg) nounwind readnone { bb: %tmp = alloca [1024 x i32], align 4 ; <[1024 x i32]*> [#uses=2] %tmp3 = getelementptr inbounds [1024 x i32]* %tmp, i32

...his? Hence, the reasonable approach as far as I know is: 3) Using f32/i32 to represent f24/i24 register, however, the problem may be: > overflow - Don't know how to solve it in LLVM > Does this approach suffer any other drawbacks? Thanks. Wei. On Nov 25, 5:22 pm, Duncan Sands <baldr... at free.fr> wrote: > 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...

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