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: [tree-ssa] DCE with control dependence again (with numbers, for a change)



On Jan 16, 2004, at 7:34 PM, law@redhat.com wrote:


In message <87llo7ju9y.fsf@codesourcery.com>, "Zack Weinberg" writes:

The level of testing being asked - and done - for this change is wildly out of proportion to the level of testing being done for other changes going onto the tree-ssa branch.
That's because we have already been down this design decision before.
Steven effectively wants to bring back code we threw out about 6 months
ago because it had some significant compile time performance concerns

Except that Steven's code doesn't, as he's quite clearly shown through multiple timings and testing *already*.


and
the increased complexity bought us nearly nothing in terms of generating
better code.


I don't see such a heavy complexity in such a standard algorithm.
The fact that the current algorithm is not one you find in books probably makes it more confusing to people than the fact that Steven's happens to do a bit more and need a bit more code.


The fact that the compile time cost is nothing, and one can find some gain in the code generated (without any regression to any other code), and the code is a perfectly standard algorithm, should be enough to get it in, but for some unknown reason, is not.

Let me turn the tables a bit:
Have you benchmarked your recent changes to the dominator optimizers using SPEC and various code size measurements, since they seem to make the dominator optimizer a bit slower (IE have some compile time cost), in order to see that they *actually* produced better code?


If you did, could you kindly include those results so that people see this is as a standard thing for algorithm improving patches, instead of it appearing to be wildly out of norm?


Personally, I'd think you'd be hard pressed to find a >1% change in SPEC because of your recent changes either, but i'm just guessing based on seeing entire new and great optimization passes produce a 1-2% SPEC difference.


IOW, I certainly agree with Zack here. To an outside observer, it looks like Steven has been put through the ringer here for no other apparent reason than it was a previous design decision by someone other than Steven. Whether this is the case or not, it's certainly not a good appearance for gcc, and not a good face to show to potential contributors.

--Dan


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