[LLVMdev] Move TargetRegisterInfo and TargetInstrInfo into libCodeGen

[Chris Lattner]

On Nov 27, 2012, at 11:51 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:

> 
> On Nov 27, 2012, at 11:23 AM, Chris Lattner <clattner at apple.com> wrote:
> 
>> On Nov 27, 2012, at 10:24 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:
>>> Would anyone object to my moving the TargetRegisterInfo and TargetInstrInfo classes into libCodeGen?
>>> 
>>> TargetInstrInfo	is already halfway there with its TargetInstrInfoImpl class implementing most shared functionality. The lib/Target/TargetInstrInfo.cpp file has two remaining functions that happen to not depend on libCodeGen, but I don't think they serve any purpose as part of libTarget.
>>> 
>>> Similarly, the functions in lib/Target/TargetRegisterInfo.cpp happen to not depend on libCodeGen, but I don't think the TRI interface has anything to offer to a libTarget client that doesn't link libCodeGen as well.
>> 
>> The original idea of the Target* classes is that they represent aspects of the target machine implementation, whereas the Machine* classes (in lib/CodeGen) represent a particular function being compiled.  I think this distinction still makes sense, and it makes sense that CodeGen is layered on top of Target.  What do you think?
> 
> That distinction is very useful, and we don't violate that anywhere AFAIK.
> 
> I also agree that Target should not depend on CodeGen because we want to be able to access MC functionality without pulling in all of CodeGen.
> 
> However, the TRI and TII classes only exist to service CodeGen. Most hooks take MachineInstr or MachineFunction arguments, making them impossible to implement without pulling in CodeGen. The implementation files for TRI and TII provide default implementations for a few hooks, but these defaults cannot depend on CodeGen.
> 
> We have shimmed the TargetInstrInfoImpl class between TII and the sub-class produced by Tablegen to work around this problem. TII-Impl.cpp is in lib/CodeGen, but the TII.cpp file in lib/Target doesn't really serve a purpose. It just has the two default methods that happen to not depend on CodeGen.
> 
> I think it is fine to keep the TII and TRI interfaces in Target, but their implementation files make most sense in CodeGen.

Ok, so you're saying that the headers should stay, but the .cpp files should move.  That is a bit weird, but I agree it's the best option.

-Chris