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