Re: ra-debug.c: why?

[Daniel Berlin <dberlin at dberlin dot org>]

On Wed, 17 Jul 2002, Zack Weinberg wrote:

> On Wed, Jul 17, 2002 at 08:03:31PM -0400, Daniel Berlin wrote:
> > 
> > > Now there are
> > > two places to edit when we want to tweak the dump format, and two
> > > different formats for developers to be familiar with. 
> > Say what?
> > The formats are different, remember, so if you are "tweaking" one, 
> > why would you need to change the other.
> [...]
> 
> I refer you to the patch I just posted, which did indeed need to
> change both.

Because you changed the format of RTL.
Which, as I said, doesn't happen often.
And when it does, updating dump files is usually the last thing to do, not 
the first.

> 
> I don't wish to get into an argument.  If the RA folks like this
> format better, that's fine.  I can see how it is more readable, if
> only because it doesn't print out all the details that are frequently
> irrelevant.  However, the implementation stinks, for two reasons:
> 
> 1) It was done by duplicating most of print-rtl.c and then tweaking it
>    around.  This is asking for trouble down the road, as people make
>    changes to RTL.  We already have too damn much near-duplicate code;
>    don't make it worse.
I didn't, as I specifically mentioned.
Nor do i claim the implementation doesn't stink.

> 
> 2) If I specify -fnew-ra -da, one dump (.22.lreg) is in a different
>    format from all the others. 

Not really, you just view it from a different perspective.
You think the format is different, when the reality is that it just 
doesn't have the code to print and rtl dump at the end of the pass added.
I view the dump it produces as the same as GCSE printing out it's hash 
table.
RA specific.

If you want to add the 6 lines or so to ra.c to dump RTL after the pass is 
done, go ahead.

>    Ignoring for the moment that most
>    people don't understand this new format 
I disagree with this.
I think it's perfectly understandable to people who understand RTL.

> and it's undocumented:
As is the tree dump stuff.

>    I'm reading through all the dump files in order to find out which
>    optimizer is buggy (I do this all the time) I have to switch mental
>    parsers in the middle, then immediately switch back again. 

Or, you could add the 6 lines to print a normal rtl dump and submit the 
patch.

>    This
>    makes it much harder to keep straight what's going on.  And, as I
>    said, it is now impossible to do diffs between the .22.lreg dump
>    and any other.

So, solve the actual problem, and print the rtl dump you want.
the dump file is already large, making it a bit larger won't hurt things.
> 
> It would be much better if print-rtl.c were parametrized to generate
> both dump formats, and if this were controlled by a global option.
> Then people could choose which dump format they like, and get *all*
> the RTL dumps in that format, facilitating comparisons.
I don't disagree, except that i don't think the format is useful to non-RA 
people, as it only omits RA irrelevant details, and thus, as a global 
option, it's kinda dumb.

But i do agree the implementation should be abstracted.


> 
> zw
> 
>