search for: dumpr

...nuary 2010 15:09, Dan Gohman wrote: > >>> Sound good? reimplement >> >> Unlimited-recursion dumping is what the existing dump routines >> already do, so it's a little odd to have a flag to allow these > > Which existing dump routines are you referring to? dumpr(). I guess it wasn't commented. It is now :-). > >> new dump routines to do the same thing. I guess you could >> refactor the old ones to call the new ones and eliminate some >> redundant code, if you wanted. > > We probably should. Ok. Dan

...ote: > >>> Sound good? reimplement > >> > >> Unlimited-recursion dumping is what the existing dump routines > >> already do, so it's a little odd to have a flag to allow these > > > > Which existing dump routines are you referring to? > > dumpr(). I guess it wasn't commented. It is now :-). Ah, one thing. dumpr uses DumpNodesr which does the "once" thing. I actually would prefer a full dump. Perhaps we shouldn't try to unify them, or maybe provide a flag to control behavior. In the past separate APIs have been prefer...

...nd good? reimplement >>>> >>>> Unlimited-recursion dumping is what the existing dump routines >>>> already do, so it's a little odd to have a flag to allow these >>> >>> Which existing dump routines are you referring to? >> >> dumpr(). I guess it wasn't commented. It is now :-). > > Ah, one thing. dumpr uses DumpNodesr which does the "once" thing. > I actually would prefer a full dump. Perhaps we shouldn't try to > unify them, or maybe provide a flag to control behavior. In the > past separ...

.../sheridan/Let?lt?s/wine-1.3.11/tools/wrc' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -DINCLUDEDIR="\"/usr/local/include/wine\"" -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wwrite-strings -Wpointer-arith -g -O2 -o dumpres.o dumpres.c gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -DINCLUDEDIR="\"/usr/local/include/wine\"" -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wwrite-strings -Wpointer-arith -g -O2 -o genres.o genres.c gcc -c -I. -I...

Hi Dan, If you set the node's action to "Custom", you should be able to interfere in the type legalisation phase (before it gets promoted to a 64-bit MUL) by overriding the "ReplaceNodeResults" function. You could either expand it to a different libcall directly there, or replace it with a target-specific node (say XXXISD::MUL32) which claims to take i64 types but you

...ration to be able to be able to go forward and match the new operation with the input operands (which were still I32 and not yet type-legalized to i64). Does this make sense to you? Here's what I am using to generate the XXXISD::MUL32: if(OpVT != MVT::i64) { //Op.getNode()->dumpr(); SDValue LHS = Op.getOperand(0); SDValue RHS = Op.getOperand(1); LHS = DAG.getNode(ISD::ZERO_EXTEND, dl, MVT::i64, LHS); RHS = DAG.getNode(ISD::ZERO_EXTEND, dl, MVT::i64, RHS); return DAG.getNode(XXXISD::MUL32, Op->getDebugLoc(), MV...

...!= E; ++I) { @@ -6008,7 +6009,7 @@ if (getRoot().getNode()) DumpNodes(getRoot().getNode(), 2, this); - errs() << "\n\n"; + dbgs() << "\n\n"; } void SDNode::printr(raw_ostream &OS, const SelectionDAG *G) const { @@ -6049,12 +6050,12 @@ void SDNode::dumpr() const { VisitedSDNodeSet once; - DumpNodesr(errs(), this, 0, 0, once); + DumpNodesr(dbgs(), this, 0, 0, once); } void SDNode::dumpr(const SelectionDAG *G) const { VisitedSDNodeSet once; - DumpNodesr(errs(), this, 0, G, once); + DumpNodesr(dbgs(), this, 0, G, once); } Index: lib...

Thanks for the information, allow maybe I can re-phrase the question or issue. Assume 64-bit register types, but integer is 32-bit. Already have table generation of the 64-bit operation descriptions. How about this modified approach? Before type-legalization, I'd really like to move all MUL I64 to a subroutine call of my own choice. This would be a form of customization, but I want this

On Jan 15, 2010, at 11:51 AM, David Greene wrote: > On Friday 15 January 2010 13:41, Dan Gohman wrote: >> On Jan 15, 2010, at 11:31 AM, David Greene wrote: >>> On Friday 15 January 2010 13:16, Dan Gohman wrote: >>>> Is it ever desirable to pass false to the "limit" argument? >>> >>> Not in the usual course of things but I figured someday

On Friday 15 January 2010 15:09, Dan Gohman wrote: > > Sound good? reimplement > > Unlimited-recursion dumping is what the existing dump routines > already do, so it's a little odd to have a flag to allow these Which existing dump routines are you referring to? > new dump routines to do the same thing. I guess you could > refactor the old ones to call the new ones and

...> :info:build config.status: creating tools/wmc/Makefile > :info:build config.status: creating tools/wrc/Makefile > :info:build ../../tools/makedep -C. -S../.. -T../.. lang.c mcl.c utils.c wmc.c write.c mcy.y > :info:build ../../tools/makedep -C. -S../.. -T../.. dumpres.c genres.c newstruc.c readres.c translation.c utils.c wrc.c writeres.c parser.y parser.l > :info:build make[1]: Nothing to be done for `all'. > :info:build make[1]: Nothing to be done for `all'. > :info:build make[1]: Nothing to be done for `all'. > :info:bui...