similar to: [LLVMdev] [PATCH] dbgs() Use

On Oct 7, 2008, at 12:04 PM, David Greene wrote: > On Friday 03 October 2008 12:06, Dan Gohman wrote: >> On Fri, October 3, 2008 9:10 am, David Greene wrote: >>> On Thursday 02 October 2008 19:32, Dan Gohman wrote: >>>> Looking at your dump() output above, it looks like the pre- >>>> selection >>>> loads have multiple uses, so even though

On Feb 26, 2010, at 2:07 PM, David Greene wrote: > On Friday 26 February 2010 10:34:41 David Greene wrote: >> On Friday 26 February 2010 09:55:32 David Greene wrote: >>> In the continuing quest to try to track down problems we're seeing >>> in >>> SelectionDAG, I added the following assert >>> toSelectionDAG::ReplaceAllUsesOfValuesWith: >>

On Friday 03 October 2008 12:06, Dan Gohman wrote: > On Fri, October 3, 2008 9:10 am, David Greene wrote: > > On Thursday 02 October 2008 19:32, Dan Gohman wrote: > >> Looking at your dump() output above, it looks like the pre-selection > >> loads have multiple uses, so even though you've managed to match a > >> larger pattern that incorporates them, they

I am working the AVR backend. It is still in the early stage. I got the following error:[ 86%] Building CXX object lib/Target/AVR/CMakeFiles/LLVMAVRCodeGen.dir/AVRISelDAGToDAG.cpp.obj AVRISelDAGToDAG.cpp C:\llvm-build\lib\Target\AVR\AVRGenDAGISel.inc(596) : error C2664: 'llvm::SDNode *llvm::SelectionDAG::SelectNodeTo(llvm::SDNode *,unsigned int,llvm::MVT,llvm::MVT,llvm::MVT,const llvm::SDValue

On Friday 26 February 2010 19:09:01 Dan Gohman wrote: > I've now looked at your latest patch. In summary, it does expose a > subtle problem. I haven't seen anything that here would lead to > observable misbehavior yet though. Well, I'm definitely observing misbehavior. I know it has something to do with local changes here but I haven't isolated it yet. >

>>Note that the isCommutable flag is only really useful for two-address instructions. If the two inputs are not constrained, nothing is really won by swapping them. Ahh i see, good to know that. >> Does the -view-*-dags output look correct? They do look correct, there are three Xmul_lohi blocks, one returns the low part copied into R14 and the rest of combinations get added and merged

I've run into a situation in isel where it seems like the selector is generating a cycle in the DAG. I have something like this: 0x215f140: v2f64 = llvm.x86.sse2.min.sd 0x215efd0, 0x21606d0, 0x215eb80 [0] 0x215efd0: i64 = Constant <647> [0] 0x21606d0: v2f64 = scalar_to_vector 0x213b8f0 [0] 0x213b8f0: f64,ch = load 0x213b780, 0x213aa90, 0x213b610 <0x2113690:0> alignment=8

I'm trying to implement *MUL_LOHI for my processor. My processor has mulxss (e.g.) that gives the 32 high bits of a 64 bit multiply. I tried this in ios2ISelDAGToDAG.cpp: /// Mul/Div with two results case ISD::SMUL_LOHI: case ISD::UMUL_LOHI: { SDValue Op1 = Node->getOperand(0); SDValue Op2 = Node->getOperand(1); AddToISelQueue(Op1);

Hi, During instruction selection, I have the following code for certain LOAD instructions: const LoadSDNode *LD = cast<LoadSDNode>(N); SDNode* LDW = CurDAG->getMachineNode(AVR::LDWRdPtr, SDLoc(N), VT, PtrVT, MVT::Other, LD->getBasePtr(), LD->getChain()); // Honestly, I have no idea what this does, but other memory // accessing instructions

On 7/29/2017 1:28 AM, Dr. ERDI Gergo via llvm-dev wrote: > Hi, > > During instruction selection, I have the following code for certain > LOAD instructions: > > const LoadSDNode *LD = cast<LoadSDNode>(N); > SDNode* LDW = CurDAG->getMachineNode(AVR::LDWRdPtr, SDLoc(N), > VT, PtrVT, MVT::Other, > LD->getBasePtr(), LD->getChain()); >

I am currently working on DAGToDAGISel class for MIPS and am trying to figure out a way to use INTRINSIC_W_CHAIN for an intrinsic which can return a value. My intrinsic is defined as: Intrinsic<[llvm_i32_ty],[llvm_i32_ty,llvm_i32_ty,llvm_i32_ty,llvm_i32_ty],[IntrReadWriteArgMem]>; i.e. it has four arguments and one return value In DAGToDAGISel when I try to pass it with four arguments and

Ok, this is really complicated. I need some TableGen experts to help here. I need a little help doing a final bit of tblgen hacking. I've hacked tblgen to handle patterns like this: let AddedComplexity = 40 in { def : Pat<(vector_shuffle (v2f64 (scalar_to_vector (loadf64 addr:$src1))), (v2f64 (scalar_to_vector (loadf64 addr:$src2))),

Hello everybody, Following on from the excellent help I received at http://comments.gmane.org/gmane.comp.compilers.llvm.devel/52591 - I have a follow up question. I've been editing the SelectionDAGiSel.cpp to try and print out the operations in the nodes, to this end I have modified the SelectionDAGISel::CodeGenAndEmitDAG() function as follows void SelectionDAGISel::CodeGenAndEmitDAG() {

On Monday 21 December 2009 10:14, Török Edwin wrote: > On 2009-12-21 18:06, David Greene wrote: > > On Saturday 19 December 2009 00:16, Chris Lattner wrote: > >>> Or I think I can just assume (Yikes!) that if the signal handler is > >>> invoked it will really be a circular_raw_ostream since the handler > >>> should (!) only be set up in debug mode. >

Hi, I am trying to debug my backend, and observe very strange behavior with dbgs(): In the IfConverter, I have added two debugging lines that print floating-point numbers for the sake of demonstration that such printing works fine. bool MeetIfcvtSizeLimit(MachineBasicBlock &BB, unsigned Cycle, unsigned Extra, const BranchProbability

Hello all, I recently foudn myself wanting to view the basic blocks in the selection DAG as pure DAGs - so just as a list of edges, with no other information. I added the below code to the start of the " void SelectionDAGISel::CodeGenAndEmitDAG()" function. It creates a separate txt file for each basic block and gives a list of edges between nodes. The segment of code is below -

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 > simplification.  There are still some issues with this patch, but does > the approach

In ARM, constants that are too large to be used as immediate are usually placed in a constant pool and loaded. What I am trying to do is to have a select function that checks the if a constant can be an immediate and, if it can't, produces a load: --------------------------------------------------------------------------------------- const Type *OpNTy =

2008/2/15, Andreas Fredriksson <deplinenoise at gmail.com>: > > I tried mocking this up using the following. (Base is what's returned as > the Ax in the move expression above when the DAG is constructed due to > SelectAddr().) > > SDOperand chain = CurDAG->getCopyToReg(Base, M68K::A3, Base); > Base = CurDAG->getCopyFromReg(chain, M68K::A3, MVT::i32);

Hey, I wanted to add an intrinsics to read MSRs. So I added the intrinsics and lowered it to a new ISD node I created ISD::RDMSR, its first operand is the MSR id. I added a case in X86DAGToDAGISel::Select for ISD::RDMSR. Now I know rdmsr works like so: mov r/ecx, <id> rdmsr r/eax holds the lower 32/64 bit >From what I understood this needs a Token Factor node, nodes which are