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: [PATCH]: Fix latent bug in tailcall


Zdenek Dvorak wrote:
> Hello,
> 
>>> anyway, it means either running ssa update, or preserving full ssa form
>>> (which we did not do for quite some time, so it would probably require
>>> some changes to other parts of gcc).
>> Honestly, i'd rather try option 2.
>>
>> I still believe the general ssa updater was a bad idea, as shown by the
>> fact that it is the source of most time spent in the middle-end on a lot
>> of testcases.
>>
>> It is simply used as a crutch for avoiding thinking about how to
>> properly update the ssa form.
> 
> when update_ssa was introduced, Diego has made some extensive
> measurements that have shown it to be in fact more efficient than the
> special case solutions we had implemented at that time, so the situation
> is more complicated. 

I don't remember this being the case, but i'll trust it's correct.

However, I firmly believe that almost all of the places we currently use
update_ssa could be done without it, faster (PRE is an example of this).
 It's just too big a hammer for *almost all* cases.

> One of major wins with update_ssa was that
> we no longer needed loop closed ssa form for virtual operands, which
> saves significant amount of memory and compile time.

Again, I have my doubts.

> 
> What are the testcases you speak about?  Perhaps reintroducing
> special-case handling and/or improving efficiency of update_ssa
> might be appropriate for them.
> 

One in particular that is easy to find is to bugzilla search for
"update_ssa slow".


> Zdenek
> 


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