similar to: [LLVMdev] Problem with SelectionDAG ordering

Hi Xiaoyi, Do you still see this behavior after r177525? I recently fixed several places where ordering was not propagated, including during legalization. There are probably still cases that are missed, but I'd be interested in seeing a missed case. I'm guessing it's a legalization that expands to multiple new nodes. The AssignOrdering calls in the legalizer may need to be expanded

void SelectionDAGBuilder::visitTargetIntrinsic(const CallInst &I, - unsigned Intrinsic) { - bool HasChain = !I.doesNotAccessMemory(); - bool OnlyLoad = HasChain && I.onlyReadsMemory(); + unsigned Intrinsic) { + // Info is set by getTgtMemInstrinsic + TargetLowering::IntrinsicInfo Info; + bool

Thanks Devang. Is there any plan on making this implicit in the node creation? Or instead of using DebugLoc in SelectionDAG, use SDDbgValue's instead, or embedding the SDDbgValue in the debug loc itself somehow? This seems like something that shouldn't have to be handled on a case by case basis in the backends. Your thoughts? Thanks, Micah From: Devang Patel [mailto:dpatel at

From: Villmow, Micah Sent: Tuesday, November 06, 2012 1:37 PM To: 'llvm-dev at cs.uiuc.edu' Cc: Guo, Xiaoyi Subject: Bug in SelectionDAG visitTargetIntrinsic We ran into a problem where specifying IntrNoMem was causing our instruction selection to fail with target specific intrinsics. After looking into the code and ISel debug it looks like tablegen and SelectionDAG are using different

On Apr 15, 2011, at 2:21 PM, Villmow, Micah wrote: > John/Richard, > I think I have found the problem to why the debug information is getting destroyed. The problem is in SelectionDAG and how it interacts with the SDDbgValue nodes and custom SDNodes. > > When the dbg_value intrinsic is encountered, it adds the debug value to a specific SD Node in

Eli, I've been working on this for a few days and still haven't gotten this towork. I've attached my dags that you asked for, and even there it is turning the floating point instruction into an integer return value. IR code just for reference: -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Villmow, Micah Sent:

Micah, There are a number of variable names in this patch that don't follow the naming convention (which specifies that they should start with an uppercase letter). > if (PtrBits < 64) > - OffsVal = DAG.getNode(ISD::TRUNCATE, getCurDebugLoc(), > - TLI.getPointerTy(), > + OffsVal = DAG.getNode(ISD::TRUNCATE,

On Mon, 27 Aug 2012 15:25:50 +0000 "Villmow, Micah" <Micah.Villmow at amd.com> wrote: > Most likely this code was added before getSExtOrTruncate was added, > but not 100% sure. It seems to assume that no pointer can be more > than 64bits in size. Does LLVM generally support pointers of greater than 64 bits? -Hal > > > -----Original Message----- > >

John/Richard, I think I have found the problem to why the debug information is getting destroyed. The problem is in SelectionDAG and how it interacts with the SDDbgValue nodes and custom SDNodes. When the dbg_value intrinsic is encountered, it adds the debug value to a specific SD Node in SelectionDAGBuilder.cpp::visitIntrinsicCall(). In one of my cases, it is vector_extract_elt. During

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.getNode(ISD::ANY_EXTEND, N0.getDebugLoc(), VT,

> -----Original Message----- > From: Fabian Scheler [mailto:fabian.scheler at gmail.com] > Sent: Thursday, August 16, 2012 4:58 AM > To: LLVM Developers Mailing List; Villmow, Micah > Cc: Stellard, Thomas; cameron.mcinally at nyu.edu > Subject: Re: [LLVMdev] More Back-End Porting Troubles > > Hi, > > first of all: thanks for your kind, very helpful and unbelievable

Most likely this code was added before getSExtOrTruncate was added, but not 100% sure. It seems to assume that no pointer can be more than 64bits in size. > -----Original Message----- > From: Hal Finkel [mailto:hfinkel at anl.gov] > Sent: Friday, August 24, 2012 4:27 PM > To: Villmow, Micah > Cc: LLVM Developers Mail > Subject: Re: [LLVMdev] FW: RFC: Supporting different sized

Ok, It doesn't work. The problem is LLVM then asserts later on in SelectionDAG:2642 because it is checking to see whether the second operand is an Integer, and if not it assumes it is floating point and asserts with the method Cannot *_EXTEND_INREG FP types. So, it seems that the root problem here is the 'MVT::Other' still hanging around. How do I convert this SDValue to an int vector

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;

-----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eli Friedman Sent: Wednesday, September 10, 2008 3:30 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Custom Lowering and fneg On Wed, Sep 10, 2008 at 2:35 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > Generating the following LLVM IR: > > define

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Fabian Scheler > Sent: Wednesday, August 15, 2012 9:12 AM > To: LLVM Developers Mailing List > Subject: [LLVMdev] More Back-End Porting Troubles > > Hi LLVM-Folks, > > as mentioned in an earlier post >

________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent: Friday, September 19, 2008 10:49 AM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Custom Opcodes versus built-in opcodes On Sep 18, 2008, at 4:04 PM, Villmow, Micah wrote: I am using lowering instructions and using custom opcodes that

Hi, first of all: thanks for your kind, very helpful and unbelievable fast response! >> as mentioned in an earlier post >> (http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-July/051677.html) I >> am currently working on a Back-End for the TriCore processor. >> Currently, I am struggling as LLVM could not select zext and load, for >> instance, so some of the testcases

> -----Original Message----- > From: Jim Grosbach [mailto:grosbach at apple.com] > Sent: Monday, November 08, 2010 10:41 AM > To: Villmow, Micah > Cc: LLVM Developers Mailing List > Subject: Re: [LLVMdev] Creating tablegen patterns for intrinsics with > no return value. > > > On Nov 8, 2010, at 10:32 AM, Villmow, Micah wrote: > > > I have intrinsic with no

I am using lowering instructions and using custom opcodes that I can more easily directly map to my backend. These opcodes are then used to emit a custom set of instructions into the MachineBasicBlock. I've been able to get one to work correctly, however, I've ran into an issue where my second one is being confused as a FRAMEADDR opcode instead of my opcode. DValue