Re: i seem to have hit a problem with my new conflict finder.

["Vladimir N. Makarov" <vmakarov at redhat dot com>]

Kenneth Zadeck wrote:

> it looks like the backwards scan is not getting "enough" interferences
> to make reload/global happy.
>
> the case comes about because of way local_alloc is preassigning regs for
> pseudos that would map into more than 1 hardreg.
>
> pseudo's are as wide as they need to be.  When local_alloc assigns one
> of these to a hard reg, it assigns it to the first hardreg needed and
> the mode is used to indicate how many of the following regs are needed.
>
> The problem comes where you have a store that uses 2 or more hard regs
> but one or more of those hardregs is unused.
>
> In a forwards scan, ALL of the set regs will interfere with anything
> live until the last set reg goes dead.  In a backwards scan, the unused
> hard regs never cause interferences.
> global/reload wants these interferences.
>
> This is, of course, one of the reasons that backward scanning the proper
> way to build an interference graph.  But something in global or reload
> cannot handle the truth.
>
> There are a lot of ways to handle this problem:
> 1) We could do a pass that breaks multiword sets into individual regs if
> some of those regs are dead.  I guess the downside of this is that such
> insns may not match some patterns anymore.
>
>  
May be it is right thing to do in long perspective but I think it is too 
complicated to implement it working.

> 2) We could turn off local.  I was planning on testing this anyway
> because i want to see if local, at this point, is just making global do
> a bad job.   However, my hope is that global or the new allocator from
> vlad is smart enough to properly handle the case where some parts of a
> multiword set are dead. 
>
>  
The local has very important part update_equiv_regs.  Without it you 
will have a serious performance degradation.

As for IRA I started work on using df-infrastructure for it.  I am not 
going to use UREC or LIVE at least at first time.  I'll use LR as it was 
in IRA before the df-infrastructure.  IRA also uses forward scan for 
building conflicts.  After making df-infrastructure working in IRA, I 
should think about using LIVE or backward scan but right now I am not 
sure that will give an improvement worth to use it.

> 3) We could fix global/reload to not be stupid.   Because, of course,
> you should be able to put something in that unused regs slot. 
>
> Any comments.
>  
Thanks for asking.  Taking into account the implementation problems I am 
not sure that the backward scan is worth to implement in gcc.  May be I 
am wrong.  Only the practice (the perfomance and compile time 
improvements) could say that.