Hi Michael- 1. We intent to fork clang for MLIR at a particular release and develop. We will mostly merge with the master as soon as we reach a good milestones. Most of the development is expected to happen in github or some such version control system. 2. MLIR is extensible and we are hoping that constructs like exceptions can be represented in MLIR. As we dive deep into design we might be able to answer the question in detail. thanks, -Prashanth On Mon, Feb 17, 2020 at 2:11 AM Michael Kruse <llvm at meinersbur.de> wrote:> Can you elaborate what your approach is? Do you intent to fork clang > for MLIR at a specific version, keep up-to-date with master and/or try > to upstream this? > > Do you think MLIR has all the semantics required, such as for > representing exceptions? > > Michael > > Am So., 16. Feb. 2020 um 03:16 Uhr schrieb Prashanth N R via flang-dev > <flang-dev at lists.llvm.org>: > > > > Starting from May-June, we at "Compiler Tree" would start porting > clang compiler to use MLIR as middle end target. If someone has already > started a similar effort we would love to collaborate with them. If someone > would like to work with us, we are ready to form a group and collaborate. > If there are sharing opportunities from Fortran side, we would like to > consider the same. > > > > We are in the early phase of design for "C" part of the work. From > our experience with (FC+MLIR) compiler, we are estimating that we would > have an early cut of the compiler working with non-trivial workload within > a quarter of starting of work. > > > > Please ping me for any queries or concerns. > > > > Regards, > > -Prashanth > > _______________________________________________ > > flang-dev mailing list > > flang-dev at lists.llvm.org > > https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200217/805a6dad/attachment.html>
On Tue, Feb 18, 2020 at 12:58 AM Prashanth N R via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi Michael- > > 1. We intent to fork clang for MLIR at a particular release and develop. > We will mostly merge with the master as soon as we reach a good milestones. > Most of the development is expected to happen in github or some such > version control system. > 2. MLIR is extensible and we are hoping that constructs like exceptions > can be represented in MLIR. As we dive deep into design we might be able to > answer the question in detail. >Speaking 1st hand here. Note: There's a number of internal lowering processes between clang and llvm and so I'll use general terms to describe it for simplicity. When "we" (PathScale) made clang emit High WHIRL instead of "whatever" it really isn't as bad as some people around here may think. I'd guess it only took us about 2 years to go from zero to production quality and self hosting. This was multiple engineers working concurrently and dealing with a lot of legacy. I could easily see it taking less time if you don't have to bring up advanced loop optimizations or care too much about EH stuff. I'm not sure how much use or value it would be to anyone, but I have and control all of that code. Briefly, we hook into clang directly after AST and then swap out the IR "codegen" for what we coined WhirlGen. I must admit that I feel a bit smug that design choices I made 10 years ago are finally being taken seriously around here. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200218/618b578e/attachment.html>
Am Mo., 17. Feb. 2020 um 10:58 Uhr schrieb Prashanth N R <prashanth.nr at gmail.com>:> 1. We intent to fork clang for MLIR at a particular release and develop. We will mostly merge with the master as soon as we reach a good milestones. Most of the development is expected to happen in github or some such version control system.Once you did the conversion, I think it becomes unfeasible to merge in LLVM master on a regular basis. For instance, you will have changed every occurrence of llvm::Instruction to mlir::Operation and its API, affecting about every line of code starting with clangCodeGen. Even if you introduce compatibility layer, upstream LLVM will continue to use llvm::Instruction. Another case is MLIR's use of BasicBlock arguments instead of PHINode. This is a change we potentially would want in LLVM as well, but would require every line that assumes PHI nodes at once, so has not been done yet. Michael
On Tue, Feb 18, 2020 at 7:04 AM Michael Kruse via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Am Mo., 17. Feb. 2020 um 10:58 Uhr schrieb Prashanth N R > <prashanth.nr at gmail.com>: > > 1. We intent to fork clang for MLIR at a particular release and develop. > We will mostly merge with the master as soon as we reach a good milestones. > Most of the development is expected to happen in github or some such > version control system. > > Once you did the conversion, I think it becomes unfeasible to merge in > LLVM master on a regular basis. For instance, you will have changed > every occurrence of llvm::Instruction to mlir::Operation and its API, > affecting about every line of code starting with clangCodeGen. Even if > you introduce compatibility layer, upstream LLVM will continue to use > llvm::Instruction. > > Another case is MLIR's use of BasicBlock arguments instead of PHINode. > This is a change we potentially would want in LLVM as well, but would > require every line that assumes PHI nodes at once, so has not been > done yet. >I don't know how they are doing it, but if they hook in after AST like we do and make a whole knew SomethingGen/ it should be possible that regular rebase will work. That internal API isn't stable, but I don't remember a ton of code churn on either sides of the API that we connected with. Of course this is anecdotal, but it's exactly the kind of feedback that may be helpful to others trying to achieve what I think they are aiming for. dum dee doo> > Michael > _______________________________________________ > 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/20200218/94c7278f/attachment.html>