[llvm-commits] [llvm] r117174 - in /llvm/trunk: include/llvm/CodeGen/LinkAllCodegenComponents.h include/llvm/CodeGen/Passes.h lib/CodeGen/CMakeLists.txt lib/CodeGen/LiveIntervalUnion.cpp lib/CodeGen/LiveIntervalUnion.h lib/CodeGen/RegAllocBase.h lib/CodeGen/RegAllocBasic.cpp lib/CodeGen/SplitKit.h

[Jakob Olesen]

On Oct 26, 2010, at 11:37 AM, Andrew Trick wrote:

> On Oct 25, 2010, at 2:58 PM, Jakob Stoklund Olesen wrote:
>>> +#include "llvm/CodeGen/LiveInterval.h"
>> 
>> Do you need this header? It looks like SlotIndexes.h is enough.
> 
> We could do that by moving certain inline functions, like overlap() into LiveIntervalUnion.cpp. But it only ever makes sense for LiveIntervalUnion users to include LiveInterval, so is it worth scattering the methods?

No. Keep it.

>>> Added: llvm/trunk/lib/CodeGen/RegAllocBasic.cpp
>>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/RegAllocBasic.cpp?rev=117174&view=auto
>>> ==============================================================================
>>> --- llvm/trunk/lib/CodeGen/RegAllocBasic.cpp (added)
>>> +++ llvm/trunk/lib/CodeGen/RegAllocBasic.cpp Fri Oct 22 18:09:15 2010
>>> @@ -0,0 +1,259 @@
>> 
>>> +class RABasic : public MachineFunctionPass, public RegAllocBase
>> 
>> Instead of using multiple inheritance, would it make sense for RegAllocBase to be a MachineFunctionPass? It seems that any register allocator using RegAllocBase would need the same pass initialization code and so on.
> 
> I was also tempted to make RegAlloc an abstract MachineFunctionPass. In fact I originally did that, and it was a bit easier write the code. But I want to give you some time to reconsider, because I don't think that design follows what you originally asked for: an implementation of the basic allocation pass that would never change and serve as a clean reference point and boilerplate code for extensions. It will be easier for others to understand the design and how to extend it if we keep RegAllocBase pure so that it only handles logic fundamental to the register allocation data structures and algorithms. Each regalloc subclass is a different type of pass, so it is responsible for all pass-related implementation. If RegAllocBase is derived from MachineFunctionPass then it will implement some of the pass setup and dependencies and the subclasses will each have to figure out what's left over and add any new dependencies--I think that's bad design and leads to scattered implementation.

Alright.

Let's leave it as is, and change it if it causes problems.

/jakob