search for: nvtbits

...n of integer shift /// of any size. bool DAGTypeLegalizer:: ExpandShiftWithUnknownAmountBit(SDNode *N, SDValue &Lo, SDValue &Hi) { SDValue Amt = N->getOperand(1); EVT NVT = TLI.getTypeToTransformTo(*DAG.getContext(), N->getValueType(0)); EVT ShTy = Amt.getValueType(); unsigned NVTBits = NVT.getSizeInBits(); assert(isPowerOf2_32(NVTBits) && "Expanded integer type size not a power of two!"); DebugLoc dl = N->getDebugLoc(); // Get the incoming operand to be shifted. SDValue InL, InH; GetExpandedInteger(N->getOperand(0), InL, InH); SDVa...

...her values have similar > errors. Below is the current and proposed expansion in pseudo C++ for > all shift functions. Please let me know if I something is unclear. I'm not sure what you are saying, here is the code for shift-left. In the case of your example, Amt = 6, VTBits = 64 and NVTBits = 32. I've added comments at the end of various lines, like this: <== Comment. if (N->getOpcode() == ISD::SHL) { <== This branch is taken if (Amt > VTBits) { <== False ... not executed ... } else if (Amt > NVTBits) { <== False ... not executed ... } else...

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

...>> errors. Below is the current and proposed expansion in pseudo C++ for >> all shift functions. Please let me know if I something is unclear. > > I'm not sure what you are saying, here is the code for shift-left. In > the case of your example, Amt = 6, VTBits = 64 and NVTBits = 32. I've > added comments at the end of various lines, like this: <== Comment. > > if (N->getOpcode() == ISD::SHL) { <== This branch is taken > if (Amt > VTBits) { <== False > ... not executed ... > } else if (Amt > NVTBits) { <== False &g...

PS: For a small optimization, in the case where Amt is bigger than 32 (or whatever NVTBits is) you might want to use an "and" to mask off the top bits of Amt rather than subtracting 32 (if Amt is 64 or greater then the result of the shift was undefined anyway, so it is ok to mask off all the upper bits).

Duncan, Thanks for committing a fix. I see that you fixed a bug in my patch with the HiL in the case of an SRA. The issue with a test case is that it will depend on the target to expose it. Like you noted in the check-in comment x86 doesn't expose the bug. The target I'm working on isn't public. Short of writing a new one for the purpose of a test case I don't know what else to

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

...&& - "This is not a shift!"); - - MVT NVT = TLI.getTypeToTransformTo(Op.getValueType()); - SDValue ShAmt = LegalizeOp(Amt); - MVT ShTy = ShAmt.getValueType(); - unsigned ShBits = ShTy.getSizeInBits(); - unsigned VTBits = Op.getValueType().getSizeInBits(); - unsigned NVTBits = NVT.getSizeInBits(); - - // Handle the case when Amt is an immediate. - if (ConstantSDNode *CN = dyn_cast<ConstantSDNode>(Amt.getNode())) { - unsigned Cst = CN->getZExtValue(); - // Expand the incoming operand to be shifted, so that we have its parts - SDValue InL, InH; - E...

...our architecture shifting by 0 doesn't cause any problems but the comment might be valid for others. Thanks, Javier On Fri, 04 Dec 2009 21:42:36 +0100, Duncan Sands <baldrick at free.fr> wrote: > PS: For a small optimization, in the case where Amt is bigger than 32 > (or whatever NVTBits is) you might want to use an "and" to mask off > the top bits of Amt rather than subtracting 32 (if Amt is 64 or greater > then the result of the shift was undefined anyway, so it is ok to mask > off all the upper bits).

On Mon, Nov 30, 2009 at 7:22 PM, Javier Martinez <javier at jmartinez.org> wrote: > Hello, > > I'm working in adding support for 64-bit integers to my target. I'm using > LLVM to decompose the 64-bit integer operations by using 32-bit registers > wherever possible and emulating support where not. When looking at the bit > shift decomposition I saw what seems to be a