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, fora change)


Steven Bosscher <s.bosscher@student.tudelft.nl> writes:

> On Saturday 17 January 2004 01:34, 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 and
>> the increased complexity bought us nearly nothing in terms of generating
>> better code.
>
> You are right.
>
> Not that we ever had this code on the tree-ssa branch -- you just
> said you had tried it.  And clearly my attempts are more successful
> than yours given that you claimed (4 months ago) that using control
> dependence in DCE would significantly slow down the compiler, and I
> have shown that it need not be so.  But still you are right.  Just
> because I have shown the numbers and you have just casted doubt
> without the proof that I've been trying to give.
>
> Consider my patch withdrawn.

We have a valued contributor, and a valuable contribution.  Perhaps
not perfect, but certainly not something which produced "significant
compile time performance concerns [and] nearly nothing in terms of
generating better code".  (I cannot speak to the complexity of the
algorithm.)  

One person stonewalls the patch, asking for - I reiterate - testing
wildly out of proportion to other changes.  As a result the patch is
withdrawn and the contributor is frustrated, and perhaps less inclined
to make further contributions.

This is precisely the sort of outcome that I was hoping could be
avoided.

disappointedly,
zw


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