[Mono-dev] [PATCH]: Rewrite instruction list handling.

David Miller davem at davemloft.net
Thu Nov 15 17:24:36 EST 2007


From: Paolo Molaro <lupus at ximian.com>
Date: Thu, 15 Nov 2007 14:09:27 +0100

> On 11/15/07 David Miller wrote:
> > All it takes is someone able to test my patch on those remaining
> > platforms and about an hour of developer time to weed out any
> > regressions.
> 
> I'm just saying that waiting for that is likely going to take
> several days, as we don't have the power to force contributors of,
> say, the alpha, hppa and mips ports to do the needed testing.
> And in the meantime you risk having to deal with any merge conflicts
> that arise with such a large patch.

If someone is able to run a test build and regression test run, I
promise to look at and fix every problem they run into on these
remaining platforms.

> > I disagree that adding a 'prev' field is the way to implement these
> > changes especially since I've done all the work already.
> 
> Changing your code to use the existing next field and adding a prev
> field should be a minimal change and it wouldn't require all the
> architectures to be updated at once, so we could commit it sooner.

Technically speaking, the 'prev' field version is going to be
inferier to what I posted, implementation wise.  With the true
list node object scheme I used, list insert and delete can be
done completely branchless.

A 'prev' node version would need to have hard-to-predict branches
in order to implement insert and delete.

This is one of many reasons I was eager to eliminate that
bb->last_ins.

It was error prone and in fact there are several bugs in the peephole
and code lowering passes on various cpu backends that my patch fixed
as a result.  Many cases did not handle deleting an instruction at the
beginning of a basic block (and thus updating bb->code, as needed)
correctly.

> If you don't have time for that, I could look at it as my time permits.

I appreciate this offer, but I don't think it's necessary.

The changes really are trivial, and any bug or regression that shows
up at this point will be in the arch specific changes only as the core
has been fully regression tested on 3 platforms.

Please work with me to find some way to run build and regression tests
on the remaining platforms and I will do everything I can to fix every
single regression or problem that shows up.

I truly believe this is much less work than starting over from scratch
with an (untested on any platform) 'prev' based implementation.

Thank you.



More information about the Mono-devel-list mailing list