On Fri, Nov 15, 2019 at 10:58 AM Fāng-ruì Sòng <maskray at google.com> wrote:> Since you are going to rewrite the mlir history anyway, you can > probably delete accidentally checked in large files if any. >Good point, I checked and this is the largest file in the history of the repo as far as I can tell: https://github.com/joker-eph/llvm-project-with-mlir/blob/master/mlir/g3doc/includes/img/view-operation.svg (155kB)> > * I don't know whether the file CONTRIBUTING.md is still appropriate, > at least for the Code of Conduct, LLVM has its own version. > * g3doc/ seems a very Google specific name. Does `docs/` work? > * bindings/python/pybind.cpp - does it have to be an in-tree plugin? > * The Apache 2 license headers are verbose. LLVM uses > SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception. >Absolutely! All of these points (except the python bindings) are on my TODO list of things to do at the time of the merge. At the moment there is just a script continuously performing the merge in my test repository so this is an exact view of the current state of the public repo. I could also try to rewrite the license in the header in all the history of the repository, but I'm not sure it won't be brittle in practice, I was planning to do an update to all the files before pushing. I'll send the final version of the repo next month, I can CC you if you'd like to review this before we push it? For the python bindings, these are intended to provide some equivalent facility to the LLVM python bindings: https://github.com/joker-eph/llvm-project-with-mlir/tree/master/llvm/bindings/python ; while they need some work at the moment, I think we will want to have bindings though. -- Mehdi> > On Fri, Nov 15, 2019 at 2:03 AM Mehdi AMINI via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > Hi, > > > > (bcc: mlir at tensorflow.org FYI) > > > > I am following-up on the integration of MLIR in LLVM as a subproject > (Re: http://lists.llvm.org/pipermail/llvm-dev/2019-October/135687.html ). > > > > We're aiming to integrate into the monorepo next month. Right now our > intent is for MLIR to live in a top-level directory in parallel to clang, > lldb, lld, etc. > > Our top option for the integration is to perform a git subtree merge to > bring the MLIR history into the monorepo, here is a prototype: > https://github.com/joker-eph/llvm-project-with-mlir > > > > If you're curious to try it, at the moment it needs a specific CMake > invocation: > > > > cmake -G Ninja ../llvm/ -DLLVM_TARGETS_TO_BUILD="host" > -DLLVM_EXTERNAL_PROJECTS=mlir -DLLVM_EXTERNAL_MLIR_SOURCE_DIR={path to > repo}/mlir/ > > > > We'll hook into -DLLVM_ENABLE_PROJECTS after landing. > > > > Let me know if you have any comment about this! > > > > Cheers, > > > > -- > > Mehdi > > > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > -- > 宋方睿 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191115/84fa300d/attachment-0001.html>
On Fri, Nov 15, 2019 at 11:15 AM Mehdi AMINI <joker.eph at gmail.com> wrote:> > On Fri, Nov 15, 2019 at 10:58 AM Fāng-ruì Sòng <maskray at google.com> wrote: >> >> Since you are going to rewrite the mlir history anyway, you can >> probably delete accidentally checked in large files if any. > > > Good point, I checked and this is the largest file in the history of the repo as far as I can tell: https://github.com/joker-eph/llvm-project-with-mlir/blob/master/mlir/g3doc/includes/img/view-operation.svg (155kB) >> >> >> * I don't know whether the file CONTRIBUTING.md is still appropriate, >> at least for the Code of Conduct, LLVM has its own version. >> * g3doc/ seems a very Google specific name. Does `docs/` work? >> * bindings/python/pybind.cpp - does it have to be an in-tree plugin? >> * The Apache 2 license headers are verbose. LLVM uses >> SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception. > > > Absolutely! All of these points (except the python bindings) are on my TODO list of things to do at the time of the merge. At the moment there is just a script continuously performing the merge in my test repository so this is an exact view of the current state of the public repo. > I could also try to rewrite the license in the header in all the history of the repository, but I'm not sure it won't be brittle in practice, I was planning to do an update to all the files before pushing. > > I'll send the final version of the repo next month, I can CC you if you'd like to review this before we push it?Sure!> For the python bindings, these are intended to provide some equivalent facility to the LLVM python bindings: https://github.com/joker-eph/llvm-project-with-mlir/tree/master/llvm/bindings/python ; while they need some work at the moment, I think we will want to have bindings though.Another thing is that after you make CMake work -DLLVM_ENABLE_PROJECTS='...;mlir;...', it'd be nice to reorder that commit to the very beginning of the MLIR history. People want to bisect and build at any commit in the pre-monorepo history. If they can only build at the last commit, that will still be very inconvenient.
On Fri, Nov 15, 2019 at 11:43 AM Fāng-ruì Sòng <maskray at google.com> wrote:> > On Fri, Nov 15, 2019 at 11:15 AM Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > On Fri, Nov 15, 2019 at 10:58 AM Fāng-ruì Sòng <maskray at google.com> wrote: > >> > >> Since you are going to rewrite the mlir history anyway, you can > >> probably delete accidentally checked in large files if any. > > > > > > Good point, I checked and this is the largest file in the history of the repo as far as I can tell: https://github.com/joker-eph/llvm-project-with-mlir/blob/master/mlir/g3doc/includes/img/view-operation.svg (155kB) > >> > >> > >> * I don't know whether the file CONTRIBUTING.md is still appropriate, > >> at least for the Code of Conduct, LLVM has its own version. > >> * g3doc/ seems a very Google specific name. Does `docs/` work? > >> * bindings/python/pybind.cpp - does it have to be an in-tree plugin? > >> * The Apache 2 license headers are verbose. LLVM uses > >> SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception. > > > > > > Absolutely! All of these points (except the python bindings) are on my TODO list of things to do at the time of the merge. At the moment there is just a script continuously performing the merge in my test repository so this is an exact view of the current state of the public repo. > > I could also try to rewrite the license in the header in all the history of the repository, but I'm not sure it won't be brittle in practice, I was planning to do an update to all the files before pushing. > > > > I'll send the final version of the repo next month, I can CC you if you'd like to review this before we push it? > > Sure! > > > For the python bindings, these are intended to provide some equivalent facility to the LLVM python bindings: https://github.com/joker-eph/llvm-project-with-mlir/tree/master/llvm/bindings/python ; while they need some work at the moment, I think we will want to have bindings though. > > > Another thing is that after you make CMake work > -DLLVM_ENABLE_PROJECTS='...;mlir;...', it'd be nice to reorder that > commit to the very beginning of the MLIR history. People want to > bisect and build at any commit in the pre-monorepo history. If they > can only build at the last commit, that will still be very > inconvenient.Another thing. Repository issue/PR references in the descriptions no longer work. Closes #211 Fix #211 You probably want to change them, probably to the full URI. -- 宋方睿
On Fri, Nov 15, 2019 at 11:43 AM Fāng-ruì Sòng <maskray at google.com> wrote:> On Fri, Nov 15, 2019 at 11:15 AM Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > On Fri, Nov 15, 2019 at 10:58 AM Fāng-ruì Sòng <maskray at google.com> > wrote: > >> > >> Since you are going to rewrite the mlir history anyway, you can > >> probably delete accidentally checked in large files if any. > > > > > > Good point, I checked and this is the largest file in the history of the > repo as far as I can tell: > https://github.com/joker-eph/llvm-project-with-mlir/blob/master/mlir/g3doc/includes/img/view-operation.svg > (155kB) > >> > >> > >> * I don't know whether the file CONTRIBUTING.md is still appropriate, > >> at least for the Code of Conduct, LLVM has its own version. > >> * g3doc/ seems a very Google specific name. Does `docs/` work? > >> * bindings/python/pybind.cpp - does it have to be an in-tree plugin? > >> * The Apache 2 license headers are verbose. LLVM uses > >> SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception. > > > > > > Absolutely! All of these points (except the python bindings) are on my > TODO list of things to do at the time of the merge. At the moment there is > just a script continuously performing the merge in my test repository so > this is an exact view of the current state of the public repo. > > I could also try to rewrite the license in the header in all the history > of the repository, but I'm not sure it won't be brittle in practice, I was > planning to do an update to all the files before pushing. > > > > I'll send the final version of the repo next month, I can CC you if > you'd like to review this before we push it? > > Sure! > > > For the python bindings, these are intended to provide some equivalent > facility to the LLVM python bindings: > https://github.com/joker-eph/llvm-project-with-mlir/tree/master/llvm/bindings/python > ; while they need some work at the moment, I think we will want to have > bindings though. > > > Another thing is that after you make CMake work > -DLLVM_ENABLE_PROJECTS='...;mlir;...', it'd be nice to reorder that > commit to the very beginning of the MLIR history. People want to > bisect and build at any commit in the pre-monorepo history. If they > can only build at the last commit, that will still be very > inconvenient.I don’t think it is possible: it requires changes in LLVM itself but also the revision pre-merge contain *only* MLIR and not LLVM: these revision won’t build as is. I think bisection in the pre-merge history will have to use “commit date” to find a compatible revision in LLVM, and at this point the need for the more verbose syntax I send earlier isn’t the more annoying part. Hopefully going back far in time is not something that will be common. — Mehdi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191115/27471b33/attachment-0001.html>
On Sat, Nov 16, 2019 at 5:25 PM Mehdi AMINI via llvm-dev < llvm-dev at lists.llvm.org> wrote:> > > On Fri, Nov 15, 2019 at 10:58 AM Fāng-ruì Sòng <maskray at google.com> wrote: > >> Since you are going to rewrite the mlir history anyway, you can >> probably delete accidentally checked in large files if any. >> > > Good point, I checked and this is the largest file in the history of the > repo as far as I can tell: > https://github.com/joker-eph/llvm-project-with-mlir/blob/master/mlir/g3doc/includes/img/view-operation.svg > (155kB) > >> >> * I don't know whether the file CONTRIBUTING.md is still appropriate, >> at least for the Code of Conduct, LLVM has its own version. >> * g3doc/ seems a very Google specific name. Does `docs/` work? >> * bindings/python/pybind.cpp - does it have to be an in-tree plugin? >> * The Apache 2 license headers are verbose. LLVM uses >> SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception. >> > > Absolutely! All of these points (except the python bindings) are on my > TODO list of things to do at the time of the merge. At the moment there is > just a script continuously performing the merge in my test repository so > this is an exact view of the current state of the public repo. > I could also try to rewrite the license in the header in all the history > of the repository, but I'm not sure it won't be brittle in practice, I was > planning to do an update to all the files before pushing. > > I'll send the final version of the repo next month, I can CC you if you'd > like to review this before we push it? > > For the python bindings, these are intended to provide some equivalent > facility to the LLVM python bindings: > https://github.com/joker-eph/llvm-project-with-mlir/tree/master/llvm/bindings/python > ; while they need some work at the moment, I think we will want to have > bindings though. >We actually already have users of these bindings. However, these bindings are using the pybind11 library, not just core Python/C interop functionality. I'm not sure that we would want to bring in an additional dependency.> > -- > Mehdi > > > >> >> On Fri, Nov 15, 2019 at 2:03 AM Mehdi AMINI via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> > >> > Hi, >> > >> > (bcc: mlir at tensorflow.org FYI) >> > >> > I am following-up on the integration of MLIR in LLVM as a subproject >> (Re: http://lists.llvm.org/pipermail/llvm-dev/2019-October/135687.html ). >> > >> > We're aiming to integrate into the monorepo next month. Right now our >> intent is for MLIR to live in a top-level directory in parallel to clang, >> lldb, lld, etc. >> > Our top option for the integration is to perform a git subtree merge to >> bring the MLIR history into the monorepo, here is a prototype: >> https://github.com/joker-eph/llvm-project-with-mlir >> > >> > If you're curious to try it, at the moment it needs a specific CMake >> invocation: >> > >> > cmake -G Ninja ../llvm/ -DLLVM_TARGETS_TO_BUILD="host" >> -DLLVM_EXTERNAL_PROJECTS=mlir -DLLVM_EXTERNAL_MLIR_SOURCE_DIR={path to >> repo}/mlir/ >> > >> > We'll hook into -DLLVM_ENABLE_PROJECTS after landing. >> > >> > Let me know if you have any comment about this! >> > >> > Cheers, >> > >> > -- >> > Mehdi >> > >> > _______________________________________________ >> > LLVM Developers mailing list >> > llvm-dev at lists.llvm.org >> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> >> -- >> 宋方睿 >> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- -- Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191118/9d67569c/attachment.html>