search for: dumprful

On Jan 15, 2010, at 1:38 PM, David Greene wrote: > 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? dumpr(). I guess it wasn't

On Friday 15 January 2010 16:23, Dan Gohman wrote: > On Jan 15, 2010, at 1:38 PM, David Greene wrote: > > 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 > > > >

On Jan 15, 2010, at 2:34 PM, David Greene wrote: > On Friday 15 January 2010 16:23, Dan Gohman wrote: >> On Jan 15, 2010, at 1:38 PM, David Greene wrote: >>> On Friday 15 January 2010 15:09, Dan Gohman wrote: >>>>> Sound good? reimplement >>>> >>>> Unlimited-recursion dumping is what the existing dump routines >>>> already do,

http://james-camerons-avatar.wikia.com Dear All, I've been using Wine happily on my Linux server for quite some years now. Even wine-1.3.9 has compiled without any issues whatsoever. But ever since yesterday, when I tried to compile the latest version 1.3.11 I'm stuck and don't know how to help myself. Please give me some ideas. As usual, I started compiling wine by

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

Thanks Tom. I really appreciate your insight. I'm able to use the customize to get the 64-bit to go to a subroutine and for the 32-bit, I am generate XXXISD::MUL32. I'm not sure then what you mean about "overriding" the ReplaceNodeResults. For ReplaceNodeResults, I'm doing: SDValue Res = LowerOperation(SDValue(N, 0), DAG); for (unsigned I = 0, E =

Here's an example patch of how dbgs() will be used. Essentially I will replace uses of errs() with dbgs(). I believe this is the correct thing to do because: - With #define NDEBUG, dbgs() == errs() - With debugging and -debug-buffer-size=0 (the default), dbgs() just passes output to errs(). - When -debug-buffer-size>0, you want to buffer ALL output so that you don't get some

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

Hello all, I was trying to install Wine on my MacBook via the Terminal. These are my system specs: odel Name: MacBook Model Identifier: MacBook2,1 Processor Name: Intel Core 2 Duo Processor Speed: 2 GHz Number Of Processors: 1 Total Number Of Cores: 2 L2 Cache (per processor): 4 MB Memory: 1 GB Bus Speed: 667 MHz Boot ROM Version: MB21.00A5.B07 SMC Version: 1.13f3 Serial Number: BLAHBLABLAH