This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Paolo Bonzini wrote:
>> 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. 
>
> He posted a patch that should avoid creating the bad REG_DEAD notes.
>
>> 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. 
>
> I am quite negative, unfortunately, that this will allow us to
> simplify the way dataflow is handled around the boundary of reload. 
> The way to go would be the instruction selection pass (aka alternative
> selection, or pre-reload) that we even have a branch for...
>
>> 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.
>
> I think it's more bugfixes than major surgery, *if you accept to add
> an additional full df scan*.  But unfortunately, I do think that an
> additional df scan is a no-no after all the pain we went through to
> eliminate them (that's what prompted the final "rush" on RTL-sharing
> verification, among other things).
>
Paolo,
I do not believe that you did that much of this part of the dataflow
port.  I believe that it was mostly seonbae and myself.  I agree that
there are going to be some bug fixes.  but there is also some
datastructures that are created early and not updated properly as you
move thru the stack of passes.  I have no fear of fixing all of the
places where we need to fix the rescanning.  I did this enough before
the dataflow commit to know that this just a matter of squashing some
finite number of simple bugs.  The problem that i have are the
datastructures like the one that computes how many stack slots are
necessary to hold values around calls.  This is computed early and was
sometimes not properly updated as things changed.  So when you computed
new/better dataflow late in the middle of the process stack, this
datastructure, and every thing that was based on the earlier information
was inconsistent.  This happened very rarely, but fixing this appeared
to be closer to the major surgery level than the simple squashing local
bugs.  (I do admit to having a certain amount of reloadaphobia - the
fear of changing  datastructures within reload, and so i may be
predicting a higher cost for fixing these problems than would be
assigned by someone who understood reload better than me).

This, as well as the cost of the rescaning, were my motivations for
doing the dataflow the way that i did.  If these two issues were not
there, i could see just fixing the rescanning issues and moving forward.
> Paolo

Kenny


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]