> Jan Hubicka wrote:
> >So while the passes are probably now well in "benchmark toy" category
> >and they will need many changes to be useful in general, I think it is
> >good to have something we can test the framework at.
>
> Do these passes actually help on benchmarks?
Yes, those help signifca
> Mark Mitchell writes:
Mark> Do these passes actually help on benchmarks?
Mark> I don't think we should be dismissive of "benchmark toy" passes if they
Mark> actually improve benchmarks significantly. We don't have to like it,
Mark> but we should accept that people are going to benchmark
Aldy Hernandez wrote:
I would obviously vote in favor of removal if the pass is unmaintained,
but if it is agreed that it will be maintained, I can commit to working
on it as soon as we merge.
My understanding is that this patch originated at IBM Haifa. Razya, can
you commit to helping Aldy
Jan Hubicka wrote:
So while the passes are probably now well in "benchmark toy" category
and they will need many changes to be useful in general, I think it is
good to have something we can test the framework at.
Do these passes actually help on benchmarks?
I don't think we should be dismissiv
> > I think that someone, though, should be committed to fixing this pass ASAP
> > after it's checked in; waiting until late August to fix it seems bad. Is
> > there someone else who can commit to working on it as a high priority after
> > the main tuples checkin?
>
> I would obviously vote in
> In terms of regressions versus mainline, the only regressions introduced by
> tuples wrt mainline are the matrix-reorg pass that still has not been
> converted. It also fixes 4 libstdc++ testcases that are currently broken
> in trunk:
Apart from the matrix-reorg regressions, there are the Di
> I think that someone, though, should be committed to fixing this pass ASAP
> after it's checked in; waiting until late August to fix it seems bad. Is
> there someone else who can commit to working on it as a high priority after
> the main tuples checkin?
I would obviously vote in favor of re
Mark Mitchell wrote on 25 July 2008 17:30:
> Steven Bosscher wrote:
>
>> If this pass is effectively unmaintained, why not just remove it?
>> Unmaintained passes that are not enabled at any optimization level are
>> usually broken anyway.
>
> That's an option, too; the question is whether it has
Steven Bosscher wrote:
If this pass is effectively unmaintained, why not just remove it?
Unmaintained passes that are not enabled at any optimization level are
usually broken anyway.
That's an option, too; the question is whether it has any value. I
don't know.
--
Mark Mitchell
CodeSourcer
Diego Novillo wrote on 25 July 2008 17:15:
> On Fri, Jul 25, 2008 at 13:03, Mark Mitchell <[EMAIL PROTECTED]>
> wrote:
>> Diego Novillo wrote:
>>
>>> In terms of regressions versus mainline, the only regressions introduced
>>> by tuples wrt mainline are the matrix-reorg pass that still has not b
On Fri, Jul 25, 2008 at 6:19 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Diego Novillo wrote:
>
>>> Why not fix that before merging, then?
>>
>> Because it is not a pass that is run by default, it is not receiving
>> active maintenance and the cost/benefit of doing it pre-merge is lower
>> than
Diego Novillo wrote:
Why not fix that before merging, then?
Because it is not a pass that is run by default, it is not receiving
active maintenance and the cost/benefit of doing it pre-merge is lower
than fixing the pass post-merge. If that is a problem, we can keep
delaying the merge until i
On Fri, Jul 25, 2008 at 13:03, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Diego Novillo wrote:
>
>> In terms of regressions versus mainline, the only regressions introduced
>> by tuples wrt mainline are the matrix-reorg pass that still has not been
>> converted.
>
> Why not fix that before merging,
Diego Novillo wrote:
In terms of regressions versus mainline, the only regressions introduced
by tuples wrt mainline are the matrix-reorg pass that still has not been
converted.
Why not fix that before merging, then?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x7
On 7/25/08 12:42 PM, Mark Mitchell wrote:
H.J. Lu wrote:
Mainline is currently broken on a few platforms:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36907
I think we should fix it first before another big merge.
Diego, what do you think?
Well, what I understand is that the breakage is d
On Fri, 25 Jul 2008, Mark Mitchell wrote:
> H.J. Lu wrote:
>
> > Mainline is currently broken on a few platforms:
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36907
> >
> > I think we should fix it first before another big merge.
>
> Diego, what do you think?
Of the 7 platforms I can t
H.J. Lu wrote:
Mainline is currently broken on a few platforms:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36907
I think we should fix it first before another big merge.
Diego, what do you think?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
On Fri, Jul 25, 2008 at 8:03 AM, Diego Novillo <[EMAIL PROTECTED]> wrote:
>
> We were discussing the status of the tuples branch on IRC today and we
> collectively agreed that it would be a good idea to merge the branch into
> mainline today.
>
> I am planning to start the merge process, but first
Diego Novillo wrote:
We were discussing the status of the tuples branch on IRC today and we
collectively agreed that it would be a good idea to merge the branch
into mainline today.
I think it would be good to post a summary of the current state. Are
there any regressions? Any known featur
We were discussing the status of the tuples branch on IRC today and we
collectively agreed that it would be a good idea to merge the branch
into mainline today.
I am planning to start the merge process, but first I wanted to freeze
mainline to minimize merge issues.
Any objections to this
20 matches
Mail list logo
