On 01/03/2019 17:26, Troy Johnson via llvm-dev wrote:> This RFC started a good discussion and I’d like to hear responses from its author > to all of the points that have been made so far. > > > > FWIW, I’m also in favor of reusing as much from Clang as practical. In fact, with> the combined repo now, it might make sense to factor out some common front end code > that both a Clang and any Flang (f18 or Fort) would use, for maintainability as well > as to avoid the perceived strangeness of a Fortran front end relying on a C front end.What part of the frontend do you think could be shared ? At least the following seems to be re-usable: - The diagnostics infrastructure - IdentifierTable - The file manager and source location infrastructure Bruno
Bruno Ricci via llvm-dev <llvm-dev at lists.llvm.org> writes:> What part of the frontend do you think could be shared ? At least the following seems > to be re-usable: > > - The diagnostics infrastructure > - IdentifierTable > - The file manager and source location infrastructureI would like to see the possibility of clang's AST being enhanced to handle Fortran. Then I believe a lot of the clang tooling (clang-query, etc.) could be more easily made to understand Fortran. I have no doubt there is a significant amount of work to do this. That's why I asked Petr about the experience of the Fort team. Is it more work to add the necessary bits to clang's AST and its tooling, or is it more work to construct a new AST ground-up and then construct all the tooling around that ground-up? I suspect the latter is more work to achieve the same quality as in clang, though depending on the ultimate goal for a Fortran frontend, it may be less (say we don't want all of the clang-style tooling for Fortran, for example). Maybe even a lot of codegen could be reused, I don't know. I am hardly a clang expert. :) OpenMP lowering could maybe also be reused, though moving that to LLVM (as I've seen discussed) would then naturally reuse it. -David
Stephen Scalpone via llvm-dev
2019-Mar-01 22:13 UTC
[llvm-dev] RFC for f18+runtimes in LLVM
Hi Bruno, Troy,
We looked early on at reusing the preprocessor and other source-file utilities
from clang. It turns out that while preprocessors look similar on the surface,
preprocessors are deeply integrated with their source language and take into
account many language syntax rules. In the f18 documentation we have two
documents that dive into more details about the differences between C and
Fortran and the nuances of the preprocessor.
We thought we might be able to reuse the clang diagnostic infrastructure, but
upon looking at the code we saw a lot of very specific C/C++ information in that
code, which seems very natural to want to keep as much semantic information as
possible for error messages. In the end, it seemed impractical to try to map
Fortran entities to C/C++ objects just for the diagnostic infrastructure.
- Steve
On 3/1/19, 9:47 AM, "llvm-dev on behalf of Bruno Ricci via llvm-dev"
<llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at
lists.llvm.org> wrote:
On 01/03/2019 17:26, Troy Johnson via llvm-dev wrote:
> This RFC started a good discussion and I’d like to hear responses from
its author
> to all of the points that have been made so far.
>
>
>
> FWIW, I’m also in favor of reusing as much from Clang as practical. In
fact, with> the combined repo now, it might make sense to factor out some
common front end code
> that both a Clang and any Flang (f18 or Fort) would use, for
maintainability as well
> as to avoid the perceived strangeness of a Fortran front end relying on
a C front end.
What part of the frontend do you think could be shared ? At least the
following seems
to be re-usable:
- The diagnostics infrastructure
- IdentifierTable
- The file manager and source location infrastructure
Bruno
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-----------------------------------------------------------------------------------
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.
-----------------------------------------------------------------------------------
Hi Steve, This seems reasonable to me. I didn't think it would be possible to reuse the preprocessor or the AST for exactly the same reason you mention (similar from far enough but lots of differences in the details). Thank you for you answer. Bruno On Fri, 1 Mar 2019, 22:13 Stephen Scalpone, <sscalpone at nvidia.com> wrote:> Hi Bruno, Troy, > > We looked early on at reusing the preprocessor and other source-file > utilities from clang. It turns out that while preprocessors look similar > on the surface, preprocessors are deeply integrated with their source > language and take into account many language syntax rules. In the f18 > documentation we have two documents that dive into more details about the > differences between C and Fortran and the nuances of the preprocessor. > > We thought we might be able to reuse the clang diagnostic infrastructure, > but upon looking at the code we saw a lot of very specific C/C++ > information in that code, which seems very natural to want to keep as much > semantic information as possible for error messages. In the end, it seemed > impractical to try to map Fortran entities to C/C++ objects just for the > diagnostic infrastructure. > > - Steve > > On 3/1/19, 9:47 AM, "llvm-dev on behalf of Bruno Ricci via llvm-dev" < > llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at lists.llvm.org> > wrote: > > > > On 01/03/2019 17:26, Troy Johnson via llvm-dev wrote: > > This RFC started a good discussion and I’d like to hear responses > from its author > > to all of the points that have been made so far. > > > > > > > > FWIW, I’m also in favor of reusing as much from Clang as practical. > In fact, with> the combined repo now, it might make sense to factor out > some common front end code > > that both a Clang and any Flang (f18 or Fort) would use, for > maintainability as well > > as to avoid the perceived strangeness of a Fortran front end relying > on a C front end. > > What part of the frontend do you think could be shared ? At least the > following seems > to be re-usable: > > - The diagnostics infrastructure > - IdentifierTable > - The file manager and source location infrastructure > > Bruno > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > > ----------------------------------------------------------------------------------- > 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/llvm-dev/attachments/20190301/db65c6f6/attachment.html>
So, for example, you plan on implementing your own equivalent to the Clang AST
matchers but for your Fortran AST?
-Troy
________________________________
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Stephen
Scalpone via llvm-dev <llvm-dev at lists.llvm.org>
Sent: Friday, March 1, 2019 4:13:10 PM
To: Bruno Ricci; llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] RFC for f18+runtimes in LLVM
Hi Bruno, Troy,
We looked early on at reusing the preprocessor and other source-file utilities
from clang. It turns out that while preprocessors look similar on the surface,
preprocessors are deeply integrated with their source language and take into
account many language syntax rules. In the f18 documentation we have two
documents that dive into more details about the differences between C and
Fortran and the nuances of the preprocessor.
We thought we might be able to reuse the clang diagnostic infrastructure, but
upon looking at the code we saw a lot of very specific C/C++ information in that
code, which seems very natural to want to keep as much semantic information as
possible for error messages. In the end, it seemed impractical to try to map
Fortran entities to C/C++ objects just for the diagnostic infrastructure.
- Steve
On 3/1/19, 9:47 AM, "llvm-dev on behalf of Bruno Ricci via llvm-dev"
<llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at
lists.llvm.org> wrote:
On 01/03/2019 17:26, Troy Johnson via llvm-dev wrote:
> This RFC started a good discussion and I’d like to hear responses from
its author
> to all of the points that have been made so far.
>
>
>
> FWIW, I’m also in favor of reusing as much from Clang as practical. In
fact, with> the combined repo now, it might make sense to factor out some
common front end code
> that both a Clang and any Flang (f18 or Fort) would use, for
maintainability as well
> as to avoid the perceived strangeness of a Fortran front end relying on
a C front end.
What part of the frontend do you think could be shared ? At least the
following seems
to be re-usable:
- The diagnostics infrastructure
- IdentifierTable
- The file manager and source location infrastructure
Bruno
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-----------------------------------------------------------------------------------
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.
-----------------------------------------------------------------------------------
_______________________________________________
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/20190301/2107f0a5/attachment.html>
> On Mar 1, 2019, at 9:47 AM, Bruno Ricci via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On 01/03/2019 17:26, Troy Johnson via llvm-dev wrote: >> This RFC started a good discussion and I’d like to hear responses from its author >> to all of the points that have been made so far. >> >> >> >> FWIW, I’m also in favor of reusing as much from Clang as practical. In fact, with> the combined repo now, it might make sense to factor out some common front end code >> that both a Clang and any Flang (f18 or Fort) would use, for maintainability as well >> as to avoid the perceived strangeness of a Fortran front end relying on a C front end. > > What part of the frontend do you think could be shared ? At least the following seems > to be re-usable: > > - The diagnostics infrastructure > - IdentifierTable > - The file manager and source location infrastructureNote that this stuff in Clang is entirely intertwined with the C preprocessor. I think (?) that fortran uses the same-ish preprocessor? If so, then this would make a lot of sense. If not, flang could still use the llvm::SourceMgr infra. I’d be really opposed to flang reusing the Clang ASTs themselves. C++ is already a complicated language and mixing all of Fortran's concerns (including a completely different object model) will make both of them *worse* than having them stand alone IMO. -Chris
Am Sa., 2. März 2019 um 11:15 Uhr schrieb Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org>:> I’d be really opposed to flang reusing the Clang ASTs themselves. C++ is already a complicated language and mixing all of Fortran's concerns (including a completely different object model) will make both of them *worse* than having them stand alone IMO.Could there be a common base class for flang and clang AST nodes? That is, an abstract class that has children()/dump()/getSourceRange()? Michael