[Openmp-dev] [RFC] Proposed interplay of Clang & Flang & LLVM wrt. OpenMP [@Flang-dev]

Guray Ozen via Openmp-dev openmp-dev at lists.llvm.org
Fri May 3 08:27:28 PDT 2019


We are in the beginning in F18/flang as you mentioned. I agree that it would be great if we have a common code generator for the frontends. However, I am not seeing any intersecting between the internals of clang and flang that we can rely on to implement "OpenMP-IRBuilder".

This would be great if the RFC is elaborated.

Best
-Guray

From: Alexey Bataev <a.bataev at outlook.com>
Sent: Friday, May 3, 2019 5:13 PM
To: Guray Ozen <gozen at nvidia.com>; Doerfert, Johannes <jdoerfert at anl.gov>
Cc: Xinmin <xinmin.tian at intel.com>; Ravi <ravi.narayanaswamy at intel.com>
Subject: Re: [RFC] Proposed interplay of Clang & Flang & LLVM wrt. OpenMP [@Flang-dev]


1. That's why it was recommended to implement it as a kind of plugin for Clang. It is a bad idea to expose clang/fortran internals to LLVM and it won't be accepted.

2. In priniciple, the idea can be implemented. But instead of the classes, you may pass functions to the codegen plugin, which know how to work with the classes in Clang/Flang.

-------------

Best regards,

Alexey Bataev
03.05.2019 11:04, Guray Ozen пишет:

Hi Johannes,



That sounds interesting. However, I have a few questions about your RFC.



From what I understand, you are suggesting a general "OpenMP-IRBuilder" where different frontends will benefit, and it will be in core-LLVM. However, the front ends may have very different AST. How do you plan to provide a common interface for different ASTs? If it will be aware of front-end ASTs, how would be a general IR builder? Also, if it is specific to AST, do you think it should be somewhere other than the core LLVM?



You also outlining in the end, so will clang still do the early outlining?



Best

- Guray



-----Original Message-----

From: flang-dev <flang-dev-bounces at lists.flang-compiler.org><mailto:flang-dev-bounces at lists.flang-compiler.org> On Behalf Of Doerfert, Johannes via flang-dev

Sent: Friday, May 3, 2019 4:35 PM

To: Alexey Bataev <a.bataev at outlook.com><mailto:a.bataev at outlook.com>

Cc: flang-dev at lists.flang-compiler.org<mailto:flang-dev at lists.flang-compiler.org>; Xinmin <xinmin.tian at intel.com><mailto:xinmin.tian at intel.com>; Ravi <ravi.narayanaswamy at intel.com><mailto:ravi.narayanaswamy at intel.com>

Subject: Re: [Flang-dev] [RFC] Proposed interplay of Clang & Flang & LLVM wrt. OpenMP [@Flang-dev]



[Respond on the flang-list to a comment on the others.]



________________________________

From: Alexey Bataev <a.bataev at outlook.com><mailto:a.bataev at outlook.com>

Sent: Thursday, May 2, 2019 11:54:14 AM

To: Doerfert, Johannes; LLVM-Dev

Cc: cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>; Openmp-dev

Subject: Re: [Openmp-dev] [RFC] Proposed interplay of Clang & Flang &

LLVM wrt. OpenMP [@Flang-dev]



What you're talking about is the late outlining, which should be the

part of the LLVM. As I understand, Intel already has preliminary

implementation of this and they promised to publish it in May.



This is completely unrelated to late outlining, which may or may not become part of LLVM:



- Late outlining is about _how_ parallelism/OpenMP is lowered in the

  front-end and potentially again later on.

- This proposal is about _where_ the encoding happens and how we keep

  Clang & Flang in-sync.



If we decide to adopt a late outlining scheme, there would be a single location where we implement it in the "front-end", the OpenMP-IRBuilder.



Also, this was discussed some time ago, if I remember it correctly,

and it was recommended to implement this common codegen as a kind of

plugin. I don't remember the final result of this discussion, though.



I don't understand this comment. What do you mean by "kind of plugin"?

Is there a record of the discussion so we could look up the final result?



Cheers,

  Johannes



-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20190503/04bd69da/attachment-0001.html>


More information about the Openmp-dev mailing list