search for: gettypetoexpandto

Displaying 11 results from an estimated 11 matches for "gettypetoexpandto".

2009 Dec 01
0
[LLVMdev] Possible bug in ExpandShiftWithUnknownAmountBit
...en if (Amt > VTBits) { <== False ... not executed ... } else if (Amt > NVTBits) { <== False ... not executed ... } else if (Amt == NVTBits) { <== False ... not executed ... } else if (Amt == 1 && TLI.isOperationLegalOrCustom(ISD::ADDC, TLI.getTypeToExpandTo(*DAG.getContext(), NVT))) { <== False ... not executed ... } else { <== This branch is taken Lo = DAG.getNode(ISD::SHL, dl, NVT, InL, DAG.getConstant(Amt, ShTy)); <== Source low part is shifted left by 6 bits Hi = DAG.getNode(ISD::OR, dl, NVT, DA...
2006 Dec 20
2
[LLVMdev] Soft-float
...> allocation of virtual registers and the like and would always return a > legal type and the other will be used just as getTypeToTransformTo > () in > LegalizeOp(), ExpandOp() and PromoteOp() and can return also illegal > types? No need to change getTypeToTransformTo(). There is a getTypeToExpandTo () that is expand the type recursively until it find a legal type. > >> It's not done simply because there isn't a need for it right now. :-) > > Since I have this need, I'll try to find a solution for this issue and > to provide a patch. Great! There are a few spot...
2009 Dec 01
2
[LLVMdev] Possible bug in ExpandShiftWithUnknownAmountBit
Hi Duncan, The problem is the implementation of the expansion. Perhaps an example can help illustrate better. Take the case of a 64-bit integer shifted left by say 6 bits and is decomposed using 32-bit registers. Because 6 is less than the 32 (the register size) the resulting low part should be equal to the source low part shifted left by 6 bits. The current implementation places a zero
2006 Dec 21
1
[LLVMdev] Possible bug in the linear scan register allocator
...like and would always > return a > > legal type and the other will be used just as getTypeToTransformTo > > () in > > LegalizeOp(), ExpandOp() and PromoteOp() and can return also > illegal > > types? > > No need to change getTypeToTransformTo(). There is a > getTypeToExpandTo > () that is expand the type recursively until it find a legal type. > > > > >> It's not done simply because there isn't a need for it right now. > :-) > > > > Since I have this need, I'll try to find a solution for this issue > and > > to...
2009 Dec 01
2
[LLVMdev] Possible bug in ExpandShiftWithUnknownAmountBit
...lse > ... not executed ... > } else if (Amt > NVTBits) { <== False > ... not executed ... > } else if (Amt == NVTBits) { <== False > ... not executed ... > } else if (Amt == 1 && > TLI.isOperationLegalOrCustom(ISD::ADDC, > TLI.getTypeToExpandTo(*DAG.getContext(), NVT))) { <== False > ... not executed ... > } else { <== This branch is taken > Lo = DAG.getNode(ISD::SHL, dl, NVT, InL, DAG.getConstant(Amt, > ShTy)); <== > Source low part is shifted left by 6 bits > Hi = DAG.getNode(ISD::OR,...
2006 Dec 22
0
[LLVMdev] Possible bug in the linear scan register allocator
...return a >>> legal type and the other will be used just as getTypeToTransformTo >>> () in >>> LegalizeOp(), ExpandOp() and PromoteOp() and can return also >> illegal >>> types? >> >> No need to change getTypeToTransformTo(). There is a >> getTypeToExpandTo >> () that is expand the type recursively until it find a legal type. >> >>> >>>> It's not done simply because there isn't a need for it right now. >> :-) >>> >>> Since I have this need, I'll try to find a solution for this issue...
2006 Dec 20
0
[LLVMdev] Soft-float
> >> d) Would it be possible with current implementation of soft-float > >> support to map f32/f64 to integer types smaller than i32, e.g. to > > >> i16? > >> I have the impression that it is not necessarily the case, since > it would require that f64 is split into 4 parts. > > > > Yes, this should be fine. > > > >> This
2006 Dec 20
2
[LLVMdev] Soft-float
> >> d) Would it be possible with current implementation of soft-float >> support to map f32/f64 to integer types smaller than i32, e.g. to >> i16? >> I have the impression that it is not necessarily the case, since it >> would require that f64 is split into 4 parts. > > Yes, this should be fine. > >> This question is more about a theoretical
2009 May 21
0
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
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
2009 May 20
2
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
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
2009 May 21
2
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
...dl, NVT, LL, RL); - Hi = DAG.getNode(Node->getOpcode(), dl, NVT, LH, RH); - break; - } - case ISD::SELECT: { - SDValue LL, LH, RL, RH; - ExpandOp(Node->getOperand(1), LL, LH); - ExpandOp(Node->getOperand(2), RL, RH); - if (getTypeAction(NVT) == Expand) - NVT = TLI.getTypeToExpandTo(NVT); - Lo = DAG.getNode(ISD::SELECT, dl, NVT, Node->getOperand(0), LL, RL); - if (VT != MVT::f32) - Hi = DAG.getNode(ISD::SELECT, dl, NVT, Node->getOperand(0), LH, RH); - break; - } - case ISD::SELECT_CC: { - SDValue TL, TH, FL, FH; - ExpandOp(Node->getOperand(2), TL...