[llvm-commits] [llvm] r76615 - in /llvm/trunk: include/llvm/CodeGen/LiveIntervalAnalysis.h lib/CodeGen/LiveIntervalAnalysis.cpp

[David Greene]

Chris Lattner wrote:

>>> 3) Is a vastly over-general solution to a very simple and specific
>>> problem.
>> This functionality will not only be used in LiveIntervals.  It will  
>> also
>> be used by the register allocator and the coalescer, at least.   
>> Basically,
>> almost anything in codegen after live interval analysis can use it.   
>> Doesn't
>> it make sense to factor the code out into a function object that can  
>> be
>> invoked from several places?
> 
> Perhaps, but it is non-obvious enough to me that it warrants  
> discussion.  If you'd like to discuss it, lets do so, but not in this  
> thread.  Please start a new one.

Fair enough.  Just for clarification, is it better to do that on
-commits or -devel?  I tend to assume discussion should be on -devel but
it's not always clear.

I should have a patch ready tomorrow.  I'll try to describe a little
better where this is going when I post it.

>> it.  It's very difficult to keep up with llvm-commits without being
>> copied explicitly on important e-mails like this.
> 
> I believe that Evan cleared this up.

Yes.  I'm running tests now.

>> Actually, what would help here is a better post-commit hook that  
>> allows
>> us to specify a subject in the commit e-mail.  git does this in a nice
>> way by assuming the log begins with a short line suitable for an e- 
>> mail
>> subject line followed by a longer descriptive paragraph.
> 
> It seems that llvm is getting significantly more active recently.   
> There are a couple of solutions to this, and your idea is a good one.   
> Long term, I'd like to split the main llvm svn repo into multiple  
> smaller ones.  This would allow us to split the codegen stuff from the  
> mid-level optimizer stuff, etc.  That way, each could have its own  
> commit list etc.  It would probably make sense to split the poolalloc,  
> llvm-gcc, gcc plugin stuff out to their own lists now.

I don't know if I like splitting the llvm repo.  That's going to be 
significant pain for those of us keeping private repositories.  It's
very difficult to create new repositories and move stuff around,
maintining history, doing merges, etc.

LLVM is a cohesive package.  The optimizer part of LLVM isn't much good
without the codegen part.  It makes sense to me to keep them together.

A better solution would be to split the commit e-mails to go to 
different lists.

And better subject lines.  :)

                         -Dave