search for: xxxregisterclass

In r155270, I removed code from TableGen that emitted XXXRegisterClass into GenRegisterInfo.inc. This value was just a const pointer to XXXRegClass. So all places that used XXXRegisterClass should be changed to &XXXRegisterClass. I already did the conversion for all targets in the tree so this is a notice to out of tree targets. One of the most common place you m...

...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 hand, as I mention...

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

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