<div dir="ltr"><div class="gmail_quote">On Wed, May 27, 2015 at 8:15 AM Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On May 26, 2015, at 11:20 PM, Quentin Colombet <<a href="mailto:qcolombet@apple.com" target="_blank">qcolombet@apple.com</a>> wrote:</div><br><div><div style="word-wrap:break-word">+1.<div><br></div><div>Could those two be subdirectories of one “Machine-Related-Stuff” directory?</div><div>E.g.,</div><div>MachineStuff/IR</div><div>MachineStuff/CodeGen</div><div><br></div><div>Where MachineStuff is something meaningful :).</div><div><br></div><div>That way, they keep a logic bound, more formal than the naming convention.</div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>Something like?</div><div><br></div><div>lib/Machine/IR</div><div>lib/Machine/Passes</div><div><br></div><div>Unless there will be many subdirectories, it seems slightly better to flatten out the layer.</div></div></div></blockquote><div><br></div><div>I strongly prefer breaking it out into subdirectories. There are a bunch of reasons:</div><div><br></div><div>1) It will grow.</div><div>2) Without it, we cannot have separate libraries, which will lose some options for shrinking the size of libraries.</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>My suggested layering would be:</div><div><br></div><div>Passes depend on IR, CodeGen depends on both Passes and IR. The idea is that anything passes require should be embedded into the IR.</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><div>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 ;-)</div></div></div></blockquote><div><br></div><div>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.</div></div></div>