Re: [RFC] Fix PR rtl-optimization/33732

[Kenneth Zadeck <zadeck at naturalbridge dot com>]

Rask Ingemann Lambertsen wrote:
> On Thu, Nov 08, 2007 at 02:23:19PM -0500, Kenneth Zadeck wrote:
>   
>> Rask,
>>
>> I want to reiterate that none of the dataflow maintainers want to pursue
>> this particular path to fix this bug. 
>>
>> All of us who worked on the dataflow branch spent a lot of time looking
>> at the bugs that came up and the performance tradeoffs and we made an
>> informed and deliberate decision to do what we did.  Lazyness or
>> stupidity were not the issues.
>>     
>
>    If I thought DF maintainers were lazy or stupid, I would have rolled my
> own loop over the insns to update the REG_DEAD notes rather than using DF.
> Posting a patch touching subsystem xyz does not imply lazyness or
> stupidity on the part of the subsystem xyz maintainers.
>
>   
>> The current stack of ra/reload passes have a fragile ordering in which
>> they build and update their internal datastructures.  Choosing a place
>> where you arbitrarily update the dataflow is going to disturb that flow
>> of information.  We have been there. 
>>     
>
>    I did not arbitrarily choose a place for a dataflow update. I
> deliberately picked a place where the REG_DEAD notes have just been
> corrupted to the point where they cause a P1 wrong-code regression. I also
> deliberately picked a place early in reload for the reason you mention.
> Lazyness or stupidity were not the issues.
>  
>   
>> I am not saying that it cannot be done, but given that we are late into
>> stage 3 AND a great deal of this code is due to be replaced in 4.4,
>> major surgery is not the correct solution. 
>>     
>
>    I'm not aware of any replacement of reload for 4.4. Until it arrives,
> we'll have to live with reload. And reload relies on REG_DEAD notes. I also
> don't know about major surgery, "late into stage 3" might just mean "great
> time for working on stage 1 stuff", etc.
>
>   
rask, i am sorry if i sounded like i went off the deep end.  but eric
seemed to have been talking about doing something very simple that
evolved just being more conservative when converting the reg dead notes,
and that seemed like the right level of fix for this problem.  I do not
know what happened with that direction. 

I do not know how aggressive that vlad is planning to be with his new
ra.  He has told me that he plans not to use reload for the spilling.  I
think that when we get a stack that looks like that, we will certainly
be able to draw a sharp line between the register allocator and what is
left of reload and start reload with a clean set of dataflow information. 

There is of course the possibility that vlad will deliver nothing and we
are stuck with what we have (though there is a plan to deliver a chaitin
based register allocator by some of us, if vlad defaults). 

however the point that i was really trying to make is that seonbae and i
tried this many many times during the df development.  we would run
various attempts of this thur a lot of code on a lot of platforms and it
would occasionally fail because of some subtle difference between what
was decided early (way too early in my estimation) and what the newly
created information would allow before reload.  Major surgery can fix
this, but there were a lot of other major surgery projects in the
dataflow port and we did not want this to be one of them.  Likewise, now
is not the time for major surgery.

We do need to get this bug fixed for stage 3.  My focus at the moment is
to look at these things as how do they move us out of stage 3.  As i
said, i was hoping that eric would turn his suggestion into a patch and
we could just move on.

Again, i am sorry if i sounded like i was biting your head off.

kenny