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

[Kenneth Zadeck <zadeck at naturalbridge dot com>]

Vladimir N. Makarov wrote:
> 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.
>
I understand that, but the actual local assignment is the part that gets
in the way of both this and the rest of allocation.  I was going to
leave that part and just turn off the local assignment.

> 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.
>
The reason that i was doing this now was because i thought we might get
some gain from it and that it is nonorthogonal to what you were doing
with IRA.  I would actually assume that you could just drop this code
in.  This was what we talked about doing at the bad Indian restaurant 
at the summit.

My main goal here was to get rid of urec, since it produces stupid
information for use with early clobbers and it is very slow.  My
enclosed patch should be a lot faster.

>> 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.
>