llvm dev - May 2015 - [LLVMdev] RFC: Separate machine IR from lib/CodeGen into lib/MIR

+1.

Could those two be subdirectories of one “Machine-Related-Stuff” directory?
E.g.,
MachineStuff/IR
MachineStuff/CodeGen

Where MachineStuff is something meaningful :).

That way, they keep a logic bound, more formal than the naming convention.

My 2c.

Q.
> On May 26, 2015, at 9:28 PM, Chris Lattner <clattner at apple.com>
wrote:
> 
> On May 26, 2015, at 1:46 PM, Owen Anderson <resistor at mac.com
<mailto:resistor at mac.com>> wrote:
>>>> The MIR serialization code will go under the new MIR library
and not under
>>>> CodeGen which will break the dependency. The CodeGen library
will link MIR
>>>> automatically so the build files for tools that link with
CodeGen won't have to
>>>> be changed.
>>>> 
>>>> Thanks for reading,
>>>> Alex
>>>> 
>>> 
>>> FWIW, I'm in favour of this.  I'd be interested to hear if
there's
>>> a reason *not* to do this.
>>> 
>>> Here's some more context:
>>> 
>>> 
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150518/278031.html
<http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150518/278031.html>
>> I have no objections, though I think lib/MachineIR would make a
prettier bikeshed ;-)
> 
> +1.  Codegen should also be renamed to something else that starts with
“Machine” as well.
> 
> -Chris
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150526/3c922c05/attachment.html>

> On May 26, 2015, at 11:20 PM, Quentin Colombet <qcolombet at
apple.com> wrote:
> 
> +1.
> 
> Could those two be subdirectories of one “Machine-Related-Stuff” directory?
> E.g.,
> MachineStuff/IR
> MachineStuff/CodeGen
> 
> Where MachineStuff is something meaningful :).
> 
> That way, they keep a logic bound, more formal than the naming convention.
Something like?

lib/Machine/IR
lib/Machine/Passes

Unless there will be many subdirectories, it seems slightly better to flatten
out the layer.

Also, if we’re getting crazy here, CodeGen in clang should be renamed to IRGen,
AsmPrinter should be renamed to MCGen, and SelectionDAG should be replaced ;-)

-Chris


> 
> My 2c.
> 
> Q.
>> On May 26, 2015, at 9:28 PM, Chris Lattner <clattner at apple.com
<mailto:clattner at apple.com>> wrote:
>> 
>> On May 26, 2015, at 1:46 PM, Owen Anderson <resistor at mac.com
<mailto:resistor at mac.com>> wrote:
>>>>> The MIR serialization code will go under the new MIR
library and not under
>>>>> CodeGen which will break the dependency. The CodeGen
library will link MIR
>>>>> automatically so the build files for tools that link with
CodeGen won't have to
>>>>> be changed.
>>>>> 
>>>>> Thanks for reading,
>>>>> Alex
>>>>> 
>>>> 
>>>> FWIW, I'm in favour of this.  I'd be interested to hear
if there's
>>>> a reason *not* to do this.
>>>> 
>>>> Here's some more context:
>>>> 
>>>> 
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150518/278031.html
<http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150518/278031.html>
>>> I have no objections, though I think lib/MachineIR would make a
prettier bikeshed ;-)
>> 
>> +1.  Codegen should also be renamed to something else that starts with
“Machine” as well.
>> 
>> -Chris
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>        
http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150527/f831f0fb/attachment.html>

On Wed, May 27, 2015 at 8:15 AM Chris Lattner <clattner at apple.com>
wrote:
> On May 26, 2015, at 11:20 PM, Quentin Colombet <qcolombet at
apple.com>
> wrote:
>
> +1.
>
> Could those two be subdirectories of one “Machine-Related-Stuff” directory?
> E.g.,
> MachineStuff/IR
> MachineStuff/CodeGen
>
> Where MachineStuff is something meaningful :).
>
> That way, they keep a logic bound, more formal than the naming convention.
>
>
> Something like?
>
> lib/Machine/IR
> lib/Machine/Passes
>
> Unless there will be many subdirectories, it seems slightly better to
> flatten out the layer.
>
I strongly prefer breaking it out into subdirectories. There are a bunch of
reasons:

1) It will grow.
2) Without it, we cannot have separate libraries, which will lose some
options for shrinking the size of libraries.
3) Without separate libraries we can't as easily enforce the layering
separations between these things. For example, making this split will be
*extremely* hard currently because there is a lot of inappropriate
dependencies that will block splitting things out.

However, "IR" and "Passes" cover only two of the things in
CodeGen. There
is also the implementation of a lot of common infrastructure used by
targets' code generators.

My initial suggestion would be to just sink CodeGen into Machine/CodeGen,
add the .../IR and .../Passes directories, and then start extracting things
from CodeGen into the two more narrow directories. I think there is likely
some stuff that should continue to live in a "code generator"
infrastructure directory as it is neither part of the machine IR, nor is it
part of any particular pass.

My suggested layering would be:

Passes depend on IR, CodeGen depends on both Passes and IR. The idea is
that anything passes require should be embedded into the IR.

However, this won't currently work. There are things that seem to be
parallel but independent of the machine IR and are used by any machine
passes. There are also things that clearly use the machine passes.
Currently, I'm not sure how to cleanly divide this library up without
really significant refactoring of every part of the code generator.

While I would like to see this happen, is it really a good idea to put this
in the critical path of getting MIR serialized and deserialized?

>
> Also, if we’re getting crazy here, CodeGen in clang should be renamed to
> IRGen, AsmPrinter should be renamed to MCGen, and SelectionDAG should be
> replaced ;-)
>
I'm happy to actually do the CodeGen -> IRGen rename. I actually built
the
change but didn't submit it because of the concerns of some out-of-tree
users of Clang. I still have all the perl scripts and such I used sitting
around.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150527/c1e3faa5/attachment.html>

> On 2015 May 27, at 08:08, Chris Lattner <clattner at apple.com>
wrote:
> 
> 
>> On May 26, 2015, at 11:20 PM, Quentin Colombet <qcolombet at
apple.com> wrote:
>> 
>> +1.
>> 
>> Could those two be subdirectories of one “Machine-Related-Stuff”
directory?
>> E.g.,
>> MachineStuff/IR
>> MachineStuff/CodeGen
>> 
>> Where MachineStuff is something meaningful :).
>> 
>> That way, they keep a logic bound, more formal than the naming
convention.
> 
> Something like?
> 
> lib/Machine/IR
> lib/Machine/Passes
> 
> Unless there will be many subdirectories, it seems slightly better to
flatten out the layer.
There are two different layers we can flatten.  We already have two
layers in lib/CodeGen.  If we flatten the second layer and go with
Quentin's idea, we get something like this:

lib/Machine/MIR
lib/Machine/Passes
lib/Machine/AsmPrinter (or MCGen)
lib/Machine/SelectionDAG (or MIRGen?)

(IMO, lib/Machine/IR is too close to lib/IR.)

If we flatten the first, we get this:

lib/MachineIR
lib/CodeGen (or MachineIRGen)
lib/CodeGen/AsmPrinter (or MCGen)
lib/CodeGen/SelectionDAG (or ...)

Both seem pretty reasonable to me, but the first one seems a little
cleaner.
> 
> Also, if we’re getting crazy here, CodeGen in clang should be renamed to
IRGen, AsmPrinter should be renamed to MCGen, and SelectionDAG should be
replaced ;-)
+1
> 
> -Chris
> 
>> 
>> My 2c.
>> 
>> Q.
>>> On May 26, 2015, at 9:28 PM, Chris Lattner <clattner at
apple.com> wrote:
>>> 
>>> On May 26, 2015, at 1:46 PM, Owen Anderson <resistor at
mac.com> wrote:
>>>>>> The MIR serialization code will go under the new MIR
library and not under
>>>>>> CodeGen which will break the dependency. The CodeGen
library will link MIR
>>>>>> automatically so the build files for tools that link
with CodeGen won't have to
>>>>>> be changed.
>>>>>> 
>>>>>> Thanks for reading,
>>>>>> Alex
>>>>>> 
>>>>> 
>>>>> FWIW, I'm in favour of this.  I'd be interested to
hear if there's
>>>>> a reason *not* to do this.
>>>>> 
>>>>> Here's some more context:
>>>>> 
>>>>> 
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150518/278031.html
>>>> 
>>>> I have no objections, though I think lib/MachineIR would make a
prettier bikeshed ;-)
>>> 
>>> +1.  Codegen should also be renamed to something else that starts
with “Machine” as well.
>>> 
>>> -Chris
>>> 
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev