[Bug tree-optimization/35805] [ira] error in start_allocno_priorities, at ira-color.c:1806

Kenneth Zadeck zadeck@naturalbridge.com
Fri Jan 2 15:34:00 GMT 2009


On looking at the code, there is an issue with the first patch.   I
should have been clearing solutions_dirty flag at the start of the
function.   However, I do not think that this is the issue that you are
complaining about.  

What this corrects is the case where the solution was dirty before the
first call to df_analyze and dce finds nothing to delete.   In that
case, the code would have redone the lr solution for no reason. 

I will test this patch, but we still need to resolve your issues with my
approach.

Kenny


zadeck at naturalbridge dot com wrote:
> ------- 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
>>   
>>     
>
>
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dce4.diff
Type: text/x-patch
Size: 2887 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20090102/cd838e06/attachment.bin>


More information about the Gcc-patches mailing list