PING^2: resubmitted IRA improvement patches

Vladimir Makarov vmakarov@redhat.com
Wed Oct 6 18:24:00 GMT 2010


  On 10/06/2010 01:23 PM, Mark Mitchell wrote:
> On 10/6/2010 7:08 AM, Vladimir Makarov wrote:
>
>> I feel there is inconsistency in you policy implementation.
> I think there's a qualitative difference between back-ends and
> front-ends and the entirety of the middle-end.  The middle-end, by
> definition, affects all users of the compiler, independent of
> programming language or target architecture.  It's vital infrastructure,
> and it makes sense to be particularly careful there.  It's a lot easier
> to get your head around how some obscure C++ language feature works, or
> what sequence of instructions is best on Power, than it is to think
> about what heuristics are going to work well across all supported CPUs.
>
> I think you're right that there is perhaps some inconsistency with the
> autovectorizer/loop optimizer vs. IRA.  Register allocation and loop
> optimization do seem to be approximately similar things.  I'm not sure
> why we have reviewers for one and maintainers for the other.
>
> But, I think you're now making a fairness argument.  That's fine, but we
> can resolve unfairness between A and B in two ways: by making A like B,
> or by making B like A.  So, first, we need to decide which one we like
> better.
>
>> I think in general removing global maintainers was a good thing.  But a
>> bad thing also happened.  You removed Richard Henderson as a global
>> maintainer, a quite actively working person who has unique wide range
>> knowledge of GCC, who has never abused this privilege and never had own
>> political agenda.
> I think it's pretty clear just how talented RTH is and how valuable his
> contributions to GCC have been.  Do you know if he has had problems
> contributing in the wake of the SC change?
>
>> I am aware about lack of knowledgeable IRA reviewers despite the facts
>> that there are four of them.  I'll work on bringing more knowledgeable
>> IRA reviewers and I know good candidates.
> That sounds constructive.
>
> I'd suggest, however, that it's not particularly constructive to
> criticize the current reviewers.  Earlier in this thread you complained
> that some of them had never contributed a patch.  That might be true,
> but that doesn't mean that they can't usefully review a patch.  Having a
> lot of knowledge about compilers and optimization research can allow
> someone to provide a useful review even without writing a lot of code in
> GCC.  Saying negative things about them isn't going to make them more
> eager to review your code.
>
> I'm a little confused with where you're trying to go with this
> conversation.  I asked that you wait for review of your patches, and you
> agreed to do so.  As I understand it, Kenny is working on reviewing
> them.  What is it that you feel is going wrong?
>
>
Well what I wanted was to avoid such situation when there is a 
possibility when patches which I believe are important skip important 
deadlines.  I also wanted to prevent IRA to become complicated as reload 
when patches which give little benefits but makes IRA too complicated 
are included in IRA because another reviewer decided to do that.

I thought that maintainership status could help me in this.  May be I 
was wrong and there are other possibilities to resolve such issues.

I am really like to see IRA as a good register allocator.  I worked very 
hard to make it.  I've tried many approaches to write better RA (I wrote 
extended linear scan register allocator, Callahan-Coblenz allocator, 
different coalescing algorithms, FAT heuristic, different RA ILP based 
models, PBQ approaches and numerous other things).

It is my baby.  And as any parent I think it is hard to lose control let 
it go but it is inevitable although I feel it is too early.

I hope that the discussion was useful at least for me.  I apologize if I 
hurt some feelings.

I also see that discussion is going nowhere and I am wasting my time 
instead of working on some more productive things.

So I'd like to stop this discussion.



More information about the Gcc-patches mailing list