dataflow branch merging plans.

[Kenneth Zadeck]

Mark Mitchell wrote:
> Bernd Schmidt wrote:
>
>   
>> Still, 6% compile time regression on several targets and typically a
>> (very small) regression in SPEC scores - am I the only one who's not
>> impressed?  We don't normally accept patches with these kinds of
>> results, and I don't see why we should make an exception here.
>>     
>
> If Kenny commits to continuing to work on these issues, I think we
> should trust him.  We've been around on this issue before, and we all
> need to bear in mind that the point of the dataflow branch is not to
> have better code immediately, but to have infrastructure that helps us
> get better code.  So, as long as we're not significantly moving
> backwards on generated code performance, I'm not worried about that
> aspect.
>
> As for compilation time, yes, that's a concern.  However, I think it's
> reasonable to move forward, as long as Kenny commits to continuing to
> work on this.  That might include, for example, converting more passes
> to use the new machinery, so as to get more benefit from it.
>
> Kenny, I think that what I would like to hear is that, roughly in order
> of urgency:
>
> (1) You will promptly address any regressions introduced by the merge
> for all targets, provided you get a decent test-case.
>
> (2) You will continue to work on integrating the new dataflow machinery
> into the compiler, to help with the compile-time performance and to help
> get better results out of the passes that roll their own dataflow stuff.
>
> (3) You will promptly fix up coding standards issues that people point out.
>
> That's what I understand you to be saying, and on that basis, I think
> you should proceed with the merge.  If there are objections from other
> global write maintainers in the next 48 hours, then let's try to get
> consensus before you go ahead.  However, I would hope that we can all
> agree to let Kenny move forward with this important piece of infrastructure.
>
> Thanks,
>
>   
Mark,

We will continue to work on these issues after the merge. 

My priorities have generally been (3) (1) (2).  The reason that I put
(3) in front is that these generally do not take any time in terms of
investigation or testing, so it is easiest to just do them and move on.

I put (1) next because these problem generally effect peoples ability to
work on gcc and it is unreasonable that this branch should hinder people
in their work.    However, the reports on the rest of the ports are
coming in generally good.  The sh, and arm are regression free.   The
mips may have one exception handling failure, but Eric seems to have hit
a similar problem to Ulrich, in that the trunk has destabilized since
our last merge and just checking regression against the latest mainline
is pretty iffy because of this instability. 

The performance issues will then be address, first with ia-64 since that
has been the odd man out.  Both seonbae and i have access to ia-64's so
access is not a problem.

Kenny