------- Comment #8 from zadeck at naturalbridge dot com 2009-01-02 15:20 ------- Subject: Re: [ira] error in start_allocno_priorities, at ira-color.c:1806
Paolo Bonzini wrote: >> I think so. The global changed flag allows it to delete the case: >> >> loop: >> ... <- x // This is dead. >> x- <- ... >> go to loop >> >> it just is not going to get rid of it if there is is no kill of x inside >> the loop. >> > > I just don't think it's acceptable to load each and every "fast DCE" > with the burden of a full df solution. We need to find a way to limit > this to the cases when it is needed, or at least not to be too > conservative in ascertaining *when* it is needed. > i am not, i am only doing it for each and every dce, only if the dce actually deletes code. If there was a faster way to determine if the solution was too conservative than redoing it, you would have an effective incremental dataflow analysis algorithm. I strongly believe that such a technique does not exist. > Hence my first and foremost question is: does it happen that the > solution is wrong and global_changed never became true? > > The example in the pr exhibits this property. the problem is that deleting the use of pseudo 69 does not cause bit 69 to ever get turned off because it was live at the bottom of the loop (since it had been propagated around the loop to start with.) Hence, when you get to the top of the loop, there are no changes at all with respect to pseudo 69 and local_changed would not have been set. (I do not know if it is really true for the example that local_changes is not set, because the deletion of the kill on the set side of the insn could have caused that to happen. But the point is that with respect to position 69, the use in the deleted insn would not have caused local_changed to be set.) > If the answer is "definitely no", then an alternative preferrable > patch would be to move the code you added to df-problems.c into dce.c, > so that the full analysis (including rebuilding the bitmaps and > iterating possibly many times) is not run if it was to yield the same > answer that was before in the bitmaps. > > Paolo > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35805