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

[zadeck at naturalbridge dot com]

------- Comment #11 from zadeck at naturalbridge dot com  2009-01-02 18:21 -------
Subject: Re:  [ira] error in start_allocno_priorities,
 at ira-color.c:1806

Paolo Bonzini wrote:
>> I will test this patch, but we still need to resolve your issues with my
>> approach.
>>     
>
> The problem is that you're really doubling the cost of computing the
> live registers.  I know that previously it was wrong, but at this point
> there's no difference with the full-blown pass...  Despite the idea of
> DF_LR_RUN_DCE being that it was "free", now it would do the same work as
> a pass_fast_rtl_dce modulo some O(#bbs) work.
>   
you are being too pessimistic.  most of the time, dce finds nothing.  
If DCE finds nothing, then the second pass does not run.

I considered just fixing the verification part (not clearing the
solutions_dirty flag) and letting the next call to df_analyze clean
things up.  In this way it would be like every other pass and leave
things dirty until the next pass that needed the info. 

StevenB talked me out of this because he considered it wrong to have the
client pass get conservative info.  I agreed with him but I am willing
to change my mind if you really want to push your case.  

> At this point, if your patch costs say 0.3%, and removing all traces of
> DF_LR_RUN_DCE (instead scheduling a dozen more pass_fast_rtl_dce in
> passes.c) costs 0.5%, I'd rather see the latter, at least it's easier to
> look for opportunities to remove some useless DCE.
>
> If it wasn't for verification, we could just decide that DF_LR_RUN_DCE
> is only for passes that can tolerate a little inaccurate info...
>
>   
This was in fact my argument to stevenb.  The point is that the live
info which is run after it will generally hide this conservativeness. 
On the other hand we do have standards that we always use the best info
.... As i pointed out on irc, the only reason that vlad noticed this at
all was that he uses the wrong sets in his code (and he was running at
O1 in this case.)  At O2 and above he should be using the DF_LIVE sets.

Kenny

> Paolo
>   


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35805