[llvm-dev] [flang-dev] About OpenMP dialect in MLIR
Vinay Madhusudan via llvm-dev
llvm-dev at lists.llvm.org
Wed Feb 19 09:00:42 PST 2020
I think it is best to have the design / implementation for few more
constructs to get more insights. I believe that the best course at this
point would be to wait for the results and act accordingly.
Thanks for the detailed and insightful discussion,
Vinay
On Tue, Feb 18, 2020 at 11:12 PM Johannes Doerfert <jdoerfert at anl.gov>
wrote:
> On 02/18, Vinay Madhusudan via flang-dev wrote:
> > Given that there are unconcluded things in this thread about OpenMP
> > representation for basic constructs (including target constructs) in MLIR
> > and OpenMPIRBuilder being the high level *common* interface for Clang AST
> > and optimized MLIR IR, I believe that it would be a good idea to wait for
> > things until there is more clarity on OpenMP in MLIR.
>
> I agree, there are open questions. However, most of them need empirical
> data to be answered properly. We cannot accurately predict what may or
> may not work wrt. optimizations that may or may not exist in the future.
>
> What I try to say is that it seems to me the path forward described by
> Kiran will bring us closer to where we want to be, at least as far as we
> can describe that point at this time. What we should aim for is an
> approach that generates useful results (=code + insight) regardless of
> potential directions changes mid-way. We obviously have to reevaluate
> choices as we go, meaning the plan is not set in stone, but that is
> always the case anyway.
>
> Please let me know if
> - you disagree with this,
> - you think the plan presented by Kiran will prevent us from
> reevaluating choices along the way and changing course accordingly,
> - you think there is a realistic chance the path will cause a
> non-trivial amount of wasted work.
Thanks,
> Johannes
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200219/a3d4b5fd/attachment.html>
More information about the llvm-dev
mailing list