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

[Kenneth Zadeck]

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
>