llvm dev - Nov 2012 - [LLVMdev] Move TargetRegisterInfo and TargetInstrInfo into libCodeGen

Hi,

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.

AFAICK, TargetMachine.cpp doesn't depend on either of these classes.

/jakob

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?

-Chris

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.

/jakob