llvm dev - Dec 2011 - [LLVMdev] moving from lib/Target and lib/CodeGen

We've had a circular dependency in LLVM for a while, and while we've
been fortunate that we could ignore it by implementing functions in
header files, a recent innocent change caused a cyclic dependency
between Target and CodeGen just because of inlining that happens in
GCC. I'm proposing to fix this by moving code from Target to CodeGen

If I understand correctly, lib/CodeGen is target-independent code
generator parts and lib/Target provides a target-independent interface
that the code in CodeGen uses, while lib/Target/Foo provides
target-specific data for, and implementations of, those target
independent pieces. The targets themselves have access to both CodeGen
and Target, and those Target-independent interfaces are defined in
terms of types in CodeGen.

This means we have two target-independent layers, one in lib/Target
(excluding subdirs) and lib/CodeGen. I think the right thing to do is
move the pieces in lib/Target which mention CodeGen types (for example
TargetInstrInfo) into CodeGen. Please let me know whether this is the
right thing to do, and meanwhile I'm going to try to prepare a patch
that does this.

Nick

Nick Lewycky wrote:
> We've had a circular dependency in LLVM for a while, and while
we've
> been fortunate that we could ignore it by implementing functions in
> header files, a recent innocent change caused a cyclic dependency
> between Target and CodeGen just because of inlining that happens in
> GCC. I'm proposing to fix this by moving code from Target to CodeGen
>
> If I understand correctly, lib/CodeGen is target-independent code
> generator parts and lib/Target provides a target-independent interface
> that the code in CodeGen uses, while lib/Target/Foo provides
> target-specific data for, and implementations of, those target
> independent pieces. The targets themselves have access to both CodeGen
> and Target, and those Target-independent interfaces are defined in
> terms of types in CodeGen.
>
> This means we have two target-independent layers, one in lib/Target
> (excluding subdirs) and lib/CodeGen. I think the right thing to do is
> move the pieces in lib/Target which mention CodeGen types (for example
> TargetInstrInfo) into CodeGen. Please let me know whether this is the
> right thing to do, and meanwhile I'm going to try to prepare a patch
> that does this.
I've gone ahead and done this. With the attached patch applied, nothing 
in lib/Target/* or include/llvm/Target/* include anything from 
include/llvm/CodeGen.

The .cpp files that moved are TargetELFWriterInfo, TargetFrameLowering, 
TargetLoweringObjectFile, TargetMachine, TargetOptions, 
TargetRegisterInfo and TargetSubtargetInfo. The .h files that moved are 
the matching headers for the .cpp files plus TargetInstrInfo, 
TargetSelectionDAGInfo and TargetLowering.

Please review! More generally, I suggest reviewing the idea of moving 
everything rather than looking at the patch itself. The patch is lots of 
changing Target/X to CodeGen/X, nothing exciting.

Nick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: target-no-codegen-llvm-1.patch
Type: text/x-diff
Size: 471265 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20111210/54a6903d/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: target-no-codegen-clang-1.patch
Type: text/x-diff
Size: 1425 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20111210/54a6903d/attachment-0001.patch>

I have mixed feeling about this. While this does separate out target-independent
pieces into CodeGen, it also introduces some confusion where the default
implementation is in CodeGen while target overridden version are in Target. I
also hate to see all these Target* classes being moved to CodeGen.

I thought our solution to this issue is classes such as TargetInstrInfoImpl.
What's wrong with it?

Evan

On Dec 10, 2011, at 7:25 PM, Nick Lewycky wrote:
> Nick Lewycky wrote:
>> We've had a circular dependency in LLVM for a while, and while
we've
>> been fortunate that we could ignore it by implementing functions in
>> header files, a recent innocent change caused a cyclic dependency
>> between Target and CodeGen just because of inlining that happens in
>> GCC. I'm proposing to fix this by moving code from Target to
CodeGen
>> 
>> If I understand correctly, lib/CodeGen is target-independent code
>> generator parts and lib/Target provides a target-independent interface
>> that the code in CodeGen uses, while lib/Target/Foo provides
>> target-specific data for, and implementations of, those target
>> independent pieces. The targets themselves have access to both CodeGen
>> and Target, and those Target-independent interfaces are defined in
>> terms of types in CodeGen.
>> 
>> This means we have two target-independent layers, one in lib/Target
>> (excluding subdirs) and lib/CodeGen. I think the right thing to do is
>> move the pieces in lib/Target which mention CodeGen types (for example
>> TargetInstrInfo) into CodeGen. Please let me know whether this is the
>> right thing to do, and meanwhile I'm going to try to prepare a
patch
>> that does this.
> 
> I've gone ahead and done this. With the attached patch applied, nothing
in lib/Target/* or include/llvm/Target/* include anything from
include/llvm/CodeGen.
> 
> The .cpp files that moved are TargetELFWriterInfo, TargetFrameLowering,
TargetLoweringObjectFile, TargetMachine, TargetOptions, TargetRegisterInfo and
TargetSubtargetInfo. The .h files that moved are the matching headers for the
.cpp files plus TargetInstrInfo, TargetSelectionDAGInfo and TargetLowering.
> 
> Please review! More generally, I suggest reviewing the idea of moving
everything rather than looking at the patch itself. The patch is lots of
changing Target/X to CodeGen/X, nothing exciting.
> 
> Nick
>
<target-no-codegen-llvm-1.patch><target-no-codegen-clang-1.patch>