[llvm-dev] [flang-dev] MLIR for clang

[C Bergström via llvm-dev]

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>