llvm dev - Jan 2010 - [LLVMdev] [PATCH] SelectionDAG Debugging

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 someone
>>> might want to dig deeper.  "limit" is just a heuristic
and it
>>> could be wrong.  Maybe the SelectionDAG is really just huge.
>> 
>> "limit" is just the flag that controls whether or not a
message
>> is printed. It seems the message would always be either useful
>> or harmless.
> 
> Ah, yes, you're correct.  I goofed there.  The message should be
> printed and "limit" should control whether we actually check
> the depth.
> 
> 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
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.

Dan

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 eliminate some
> redundant code, if you wanted.
We probably should.

                            -Dave

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 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