[LLVMdev] RFC: Separate machine IR from lib/CodeGen into lib/MIR

[Sean Silva]

On Wed, May 27, 2015 at 11:11 AM, Hal Finkel <hfinkel at anl.gov> wrote:

> ----- Original Message -----
> > From: "Duncan P. N. Exon Smith" <dexonsmith at apple.com>
> > To: "Chandler Carruth" <chandlerc at google.com>
> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
> > Sent: Wednesday, May 27, 2015 12:59:23 PM
> > Subject: Re: [LLVMdev] RFC: Separate machine IR from lib/CodeGen into
> lib/MIR
> >
> > > On 2015 May 27, at 10:24, Chandler Carruth <chandlerc at google.com>
> > > wrote:
> > >
> > >> 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.
> > >
> >
> > (Oops, missed this until after I sent my own response.
> >
> > One thing I'd add to this from my email is that I think
> > lib/Machine/IR is likely to get confused with lib/IR for the same
> > reasons that lib/CodeGen is confusing between LLVM and Clang.  IMO
> > lib/Machine/MIR is "safer".)
>
> +1 -- Please only use IR to refer to LLVM IR. We should use some different
> abbreviation for any other IR we have in the backend.
>

Also, "MIR" is also widely used in the literature and compiler textbooks to
refer to what we call "IR", so "MIR" is confusing anyway.

-- Sean Silva


>
> >
> > > 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?
> >
> > Not if it's as hard as you're saying.  My impression was that Alex
> > was able to move the IR stuff he needed into a separately library
> > pretty trivially (based on the P.O.C. patch he posted), but if it's
> > not trivial he should just move on.
> >
> > >> 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.
> >
> > I'm a really big fan of this.
>
> +1 -- Me too.
>
>  -Hal
>
>  If you supply the perl scripts
> > somehow (attached to a PR that you reference in the commit?) then
> > out-of-tree users shouldn't have a problem.  Unless I'm missing
> > something?
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>
> _______________________________________________
> 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/20150527/4248e122/attachment.html>