search for: sign_extend_inreg

Thanks Eli, I'll see if I can get something working and submit a patch. Micah -----Original Message----- From: Eli Friedman [mailto:eli.friedman at gmail.com] Sent: Wednesday, December 09, 2009 11:18 PM To: Villmow, Micah Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] SplitVecRes with SIGN_EXTEND_INREG unsupported On Wed, Dec 9, 2009 at 8:40 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > I have code that is generating sign extend in reg on a v8i32, but the > backend does not support this data type.  This then asserts in > LegalizeVectorTypes.cpp:389 because there is no fun...

...he LHS SDValue. This causes a split on the LHS side to work correctly, but then it fails instruction selection because of Other. I have not been able to figure out how to split the MVT::Other node yet, any idea how to do this? Instruction selection fails because it cannot match the pattern: v4i8 = sign_extend_inreg <v4i8 node>, <Other node(v8i8 VTSDNode)> The reason being my initial implementation based on the advice given takes as input: v8i8 = sign_extend_inreg <v8i8 node>, <Other node(v8i8 VTSDNode)> and generates two: v4i8 = sign_extend_inreg <v4i8 node>, <Other node(v8i8...

After more digging, it seems that the SIGN_EXTEND_INREG is getting generated in DAGCombiner.cpp:3033. // fold (sext (truncate x)) -> (sextinreg x). if (!LegalOperations || TLI.isOperationLegal(ISD::SIGN_EXTEND_INREG, N0.getValueType())) { if (Op.getValueType().bitsLT(VT)) Op = DAG.get...

...plain about? Thanks, Micah > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Villmow, Micah > Sent: Thursday, December 10, 2009 3:30 PM > To: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] SplitVecRes with SIGN_EXTEND_INREG unsupported > > Eli, > I think I was able to get it working. Thanks for the help, does this > look correct to you? > > void DAGTypeLegalizer::SplitVecRes_SIGN_EXTEND_INREG(SDNode *N, SDValue > &Lo, > SDValue &Hi) { > S...

Eli, I think I was able to get it working. Thanks for the help, does this look correct to you? void DAGTypeLegalizer::SplitVecRes_SIGN_EXTEND_INREG(SDNode *N, SDValue &Lo, SDValue &Hi) { SDValue LHSLo, LHSHi; GetSplitVector(N->getOperand(0), LHSLo, LHSHi); DebugLoc dl = N->getDebugLoc(); EVT LoVT, HiVT; GetSplitDestVTs(N->getValueType(1), LoVT, HiVT); Lo = DAG.getNode(N-&gt...

...reg on a v8i32, but the > backend does not support this data type.  This then asserts in > LegalizeVectorTypes.cpp:389 because there is no function to split this > vector into smaller sizes. Would a correct solution be to add this case so > to trigger the SplitVecRes_BinaryOp function? SIGN_EXTEND_INREG isn't a binary operation; the correct expansion is expanding the first operand the same way SplitVecRes_BinaryOp does, while passing through the second operand untouched. But yes, adding a case to DAGTypeLegalizer::SplitVectorResult is the right idea. If anyone else is curious, here's a t...

I have code that is generating sign extend in reg on a v8i32, but the backend does not support this data type. This then asserts in LegalizeVectorTypes.cpp:389 because there is no function to split this vector into smaller sizes. Would a correct solution be to add this case so to trigger the SplitVecRes_BinaryOp function? This asserts on both my backend and x86 and TOT does not seem to have

...t I can look at on how to split a VTSDNode? Thanks, Micah > -----Original Message----- > From: Eli Friedman [mailto:eli.friedman at gmail.com] > Sent: Thursday, December 10, 2009 1:25 PM > To: Villmow, Micah > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] SplitVecRes with SIGN_EXTEND_INREG unsupported > > On Thu, Dec 10, 2009 at 12:46 PM, Villmow, Micah > <Micah.Villmow at amd.com> wrote: > > Eli, > >  I have a simple SplitVecRes function that implements what you > mentioned, splitting the LHS just as in BinaryOp, but passing through > the RHS. The p...

On Thu, Dec 10, 2009 at 12:46 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > Eli, >  I have a simple SplitVecRes function that implements what you mentioned, splitting the LHS just as in BinaryOp, but passing through the RHS. The problem is that the second operand is MVT::Other, but when casted to an VTSDNode reveals that it is a vector length of the same size as the LHS

...xtVT))" is > supposed to ensure that the transformation in question is safe. That > said, IIRC I fixed a bug there recently; are you using trunk? Perfect! I'm using 2.8 for now (am hoping to roll forward to trunk and stay there in a month or two), and 2.8 only had that check for SIGN_EXTEND_INREG, not SRL or others. The bugfix was in r124587. I'm now seeing a similar problem with SimplifyDemandedBits() on a 4-byte-aligned i8 load. LowerLOAD() emits an aligned LD4 followed by an AND with constant 0xFF. SimplifyDemandedBits() sees this and changes it to a zero-extended LD1. Is thi...

...> supposed to ensure that the transformation in question is safe.  That >> said, IIRC I fixed a bug there recently; are you using trunk? > > Perfect!  I'm using 2.8 for now (am hoping to roll forward to trunk and stay > there in a month or two), and 2.8 only had that check for SIGN_EXTEND_INREG, > not SRL or others.  The bugfix was in r124587. > > I'm now seeing a similar problem with SimplifyDemandedBits() on a > 4-byte-aligned i8 load.  LowerLOAD() emits an aligned LD4 followed by an AND > with constant 0xFF.  SimplifyDemandedBits() sees this and changes it to a >...

On Wed, Jul 27, 2011 at 2:28 PM, Matt Johnson <johnso87 at crhc.illinois.edu> wrote: > Hi All, >     I'm writing a backend for a target which only supports 4-byte, > 4-byte-aligned loads and stores.  I custom-lower all {*EXT}LOAD and > STORE nodes in TargetISelLowering.cpp to take advantage of all alignment > information available to the backend, rather than treat each

...phi i32 [ 0, %if.then ], [ 1, %if.else ] ret i32 %retval.0 } The 'select' instruction is changed to 'xor' instruction and 'sext' instruction. Finally, code generator uses above IR code to make machine level code and generates more instruction or pattern, such as 'sign_extend_inreg', in order to process 'i1' type value . Could someone let me know which cases get advantages from this transformation? I think this transformation generates a little bit redundant instructions than without this. Thanks, JinGu Kang -- JinGu Kang Codeplay Software Ltd 45 York Place...

...for more than 10000msec" "GPU lockup (waiting for 0x00000000001023cf last fence id 0x00000000001023ce on ring 0)" although the actual test results follow the same result as before (random failures mostly in float8/16 tests). I can even get test pass with hang on every subtest Using SIGN_EXTEND_INREG instead of "SUB 0" in this patch gets rid of the hangs, and makes the failures fully reproducible in every subtest, triggered on the first occurrence of what should have been -0.925879. the GPU is AMD TURKS (HD 7570 1002:675d) I tried digging throught he manual but it oly mentions that...

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

..., dl, - Node->getOperand(0).getValueType()); - break; - case ISD::SIGN_EXTEND: - Result = PromoteOp(Node->getOperand(0)); - Result = DAG.getNode(ISD::ANY_EXTEND, dl, Op.getValueType(), Result); - Result = DAG.getNode(ISD::SIGN_EXTEND_INREG, dl, Result.getValueType(), - Result, - DAG.getValueType(Node->getOperand(0).getValueType())); - break; - } + Tmp1 = LegalizeOp(Node->getOperand(0)); + Result = DAG.UpdateNodeOperands(Result, Tmp1); + if (TLI.getOperati...

Hi All, I'm writing a backend for a target which only supports 4-byte, 4-byte-aligned loads and stores. I custom-lower all {*EXT}LOAD and STORE nodes in TargetISelLowering.cpp to take advantage of all alignment information available to the backend, rather than treat each load and store conservatively, which takes O(10) instructions. My target's allowsUnalignedMemoryOperations()

On May 24, 2008, at 11:43 AM, Marcel Moolenaar wrote: > All, > > So far I've tried LLVM on amd64, i386, ia64 and powerpc under FreeBSD > and aside for ia64, things look pretty good for a first try. There > are 2 unexpected failures for PowerPC, which appear to be caused by > uninitialized memory. I'm still working on a fix for that (need to > brush up on my C++

All, So far I've tried LLVM on amd64, i386, ia64 and powerpc under FreeBSD and aside for ia64, things look pretty good for a first try. There are 2 unexpected failures for PowerPC, which appear to be caused by uninitialized memory. I'm still working on a fix for that (need to brush up on my C++ skills). [sidenote: In FreeBSD -current, the memory allocator initializes memory with 0xa5