search for: getintegervt

...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 -> i24 can be done generically. > 2) If we use MVT::getIntegerVT() to get i24 LLVM type, then the > problem will be: > > target independent codegen's legalizer can not handle this. > Because the type legalizer currently assumes that all legal integer > types have a power-of-two number of bits. If i24 is added as a simple value type, then th...

...iors 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 fairly long code sequence: that's just fine within LLVM. 2) If we use MVT::getIntegerVT() to get i24 LLVM type, then the problem will be: > target independent codegen's legalizer can not handle this. Because the type legalizer currently assumes that all legal integer types have a power-of-two number of bits. > target independent codegen needs to be taught the i24 type. T...

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

...he 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 -> i24 can be done generically. > > > 2) If we use MVT::getIntegerVT() to get i24 LLVM type, then the > > problem will be: > >   > target independent codegen's legalizer can not handle this. > > Because the type legalizer currently assumes that all legal integer > > types have a power-of-two number of bits. > > If i24 is added as...

...t;> 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 -> i24 can be done generically. >> >>> 2) If we use MVT::getIntegerVT() to get i24 LLVM type, then the >>> problem will be: >>> > target independent codegen's legalizer can not handle this. >>> Because the type legalizer currently assumes that all legal integer >>> types have a power-of-two number of bits. >> >&gt...

...115815) +++ CodeGen/SelectionDAG/TargetLowering.cpp (working copy) @@ -1899,7 +1899,9 @@ else bestOffset = (uint64_t)offset * (width/8); bestMask = Mask.lshr(offset * (width/8) * 8); - bestWidth = width; + EVT NewVT = EVT::getIntegerVT(*DAG.getContext(), width); + if (isNarrowingProfitable(Lod->getMemoryVT(), NewVT)) + bestWidth = width; break; } newMask = newMask << width;

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

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

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, Wei wrote:

Because each channel contains 24-bit, so.. what is the llvm::SimpleValueType I should use for each channel? the current llvm::SimpleValueType contains i1, i8, i16, i32, i64, f32, f64, f80, none of them are fit one channel (24-bit). I think I can use i32 or f32 to represent each 24-bit channel, if the runtime result of some machine instructions exceeds 23-bit (1 bit is for sign), then it is an

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant

...HiOps[1] = RHSH; - - //cascaded check to see if any smaller size has a a carry flag. - unsigned OpV = Node->getOpcode() == ISD::ADD ? ISD::ADDC : ISD::SUBC; - bool hasCarry = false; - for (unsigned BitSize = NVT.getSizeInBits(); BitSize != 0; BitSize /= 2) { - MVT AVT = MVT::getIntegerVT(BitSize); - if (TLI.isOperationLegalOrCustom(OpV, AVT)) { - hasCarry = true; - break; - } - } - - if(hasCarry) { - SDVTList VTList = DAG.getVTList(LHSL.getValueType(), MVT::Flag); - if (Node->getOpcode() == ISD::ADD) { - Lo = DAG.getNode(ISD::ADDC,...