This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Clean up edge_def's crossing_edge field



On Aug 18, 2004, at 4:14 PM, Steven Bosscher wrote:


On Thursday 19 August 2004 01:05, Caroline Tice wrote:
On Aug 18, 2004, at 3:49 PM, Steven Bosscher wrote:
On Thursday 19 August 2004 00:45, Caroline Tice wrote:
Before you commit this, if it's not already too late, you should do a
profiledbootstrap, with all debugging flags
turned off (you will have to edit Makefile.in). Just to make sure
your
change doesn't mess up the hot/cold partitioning please.

Actually, no, you should have fixed this long ago, when I and others asked you to.

At the time

, which was four months ago,

Yes. As you may have noticed from the size of my update patch, I had a lot
of other things I had to fix as well. If you look closely at my patch posting, I state
up front that I did not address *all* the concerns, and that there were some efficiency
concerns (yours among them) that I meant to address later.




you asked me to change from using a boolean field into
wrapping this
into the flags fields, I explained that I considered that to be a pure
matter of taste,

, while others had already expressed the same concern, and the "matter of taste" for GCC means a flag (but then, you don't really care about gcc, do you?)

What others? You were the only person I recall asking for this change? On what basis do you assume I don't really care about gcc?



that there was no pressing technical reason to make such a change,

, in your opinion,


and that I wanted to focus
first on fixing potential correctness issues. Doing it your ways saves
a very modest amount of space;

It is not so modest, really. Especially if you realize that we put these
things in GC memory so making them smaller may put them in a smaller page
order, and when you think about keeping the CFG around in memory for every
function, like we're doing on the tree-profiling branch.




If this is such a major issue for you, I am surprised you didn't say anything about it
during the month my update patch was "out there" for review. If this really is such a
huge space gain as you claim, and my changes are really so much worse than any of
the other numerous space-consuming changes that have been added to gcc recently
then I understand your desire to make this change. But I still don't believe it gives you
the right to insult me.


-- Caroline Tice
ctice@apple.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]