[Flang-dev] new Flang discussions?

Jeff Hammond jeff.science at gmail.com
Fri Oct 12 12:25:34 EDT 2018

It’s too bad it’s too late to have BoF at LLVM conference next week about this (I’ll not be there but I’m sure many others will be). 

This is certainly a good topic to discuss with cfe-dev, not just because of Fortran. I’m excited to see things that help Rust, Chapel, etc. 

Array notation in AST might be there for OpenMP already. The target data construct includes that syntax.


Sent from my iPhone

> On Oct 12, 2018, at 9:15 AM, David Greene <dag at cray.com> wrote:
> When you say face-to-face, who was in that discussion?  flang and clang
> people?
> Is it worth kicking off a cross-post cfe-dev/flang-dev discussion or do
> we really think this is completely infeasible?
> How many "real" Fortran code use these odd corners of the language?
> Dusty decks might but maybe a 98% solution is good enough.  Doing things
> like redefining constants just seems evil to me.  Keywords are a bit
> easier to understand, as the committee likely didn't want to break old
> codes when introducing new keywords.
> I would like to better understand the AST mutating problem you mention
> and how it relates to clang.  flang presumably has to do the
> analysis/transformation already.  Is there something particularly
> bad/difficult with requiring tooling to work on a post-cleanup AST?
>                            -David
> "McCormick, Pat via flang-dev" <flang-dev at lists.flang-compiler.org>
> writes:
>> This is a fun can of worms… 
>> We've had some face-to-face discussions about this and unfortunately I
>> can’t remember the full laundry list of details. One aspect of Fortran
>> that stuck in my brain that has rarely become evident to me when
>> looking at code is that Fortran keywords are specifically not reserved
>> words. It is in the standard(s)… Someone from PGI/NVIDIA will have to
>> help refresh my memory about our full discussions in this regard; they
>> have way more experience dealing with such nuances of Fortran than I
>> do. 
>> My take (but I’m rusty) is that this introduces some
>> oddities/subtleties and corner cases that are potentially messy in
>> borrowing some infrastructure from Clang — it would seem a Fortran AST
>> would only be sound after a second evaluation pass (i.e. you have to
>> have a full construct to “understand" it). In the end, you potentially
>> have to mutate node types and maybe even the overall AST structure to
>> address this.
>> I honestly can’t come up with a (good) reason why I would want to
>> program this way — maybe someone else knows the motivations behind
>> this decision in the standard(s)? Anyways, my eventual take away was
>> this seems to fundamentally be at odds with some of the Clang design
>> philosophies. Someone can refresh my memory here if I’ve missed
>> something… 
>> All that said, the tooling aspects of this thread are extremely high
>> on our “wish list" — it is actually the most requested feature and the
>> fundamental reason our application teams are excited about Flang. It
>> would be good to get a laundry list from the community about some
>> requirements and features in this area… 
>> —Pat
>>    On Oct 11, 2018, at 9:09 AM, Jeff Hammond <jeff.science at gmail.com>
>>    wrote:
>>    On Thu, Oct 11, 2018 at 8:03 AM Roger Ferrer Ibáñez
>>    <rofirrim at gmail.com> wrote:
>>        Hi all,
>>        I'm also very interested in the source-level tooling
>>        opportunities that may arise due to f18.
>>        I work in a supercomputing center where several HPC
>>        applications are written by domain experts, but not
>>        necessarily experts in Fortran, whose work can benefit a lot
>>        from tools that operate at the source-level.
>>        Having taken the approach in the past of trying to reuse as
>>        much as C/C++ ASTs for Fortran in our in-house tools, I have
>>        to admit I'm not really enticed by the idea. After all the two
>>        languages are very different. In terms of memory/storage
>>        representation I guess this makes sense, but trying to mold
>>        Fortran language parts into "similar enough" C/C++ trees
>>        appeals less so to me. At least that has been my experience in
>>        the past. However, I also understand that in circumstances
>>        where the functionality to implement is the same as for C/C++,
>>        not being able to reuse code due to language-specific
>>        differences can be seen as a burden.
>>    Can you give some examples of how the languages are very different
>>    in a way that would make reuse of the C/C++ AST ineffective? I
>>    understand how the syntax is different, but I don't see major
>>    semantic differences that would prevent AST reuse.
>>    While C/C++ might not have a feature equivalent to coarrays (which
>>    aren't supported in Flang yet anyways), LLVM supports the concept
>>    of an address space already and thus should be able to support
>>    tooling for that if necessary.
>>    Jeff
>>        Regarding the command-line, looks very reasonable to me to
>>        make them closer to clang (in a fashion similar to what
>>        gfortran can do respect to gcc/g++), but Fortran users are
>>        (unavoidably) used to have to deal with different compilers
>>        each one having their own style and sets of command-line
>>        parameters, so perhaps there is less interest here.
>>        Reusing as much infrastructure as possible as long as it does
>>        not concern strictly to the source language also makes sense
>>        to me.
>>        Kind regards,
>>        Roger
>>        Missatge de David Greene <dag at cray.com> del dia dj., 11 d’oct.
>>        2018 a les 16:41:
>>        blubee blubeeme <gurenchan at gmail.com> writes:
>>> I think this new version of F18 will still parse and
>>            generate token
>>> streams but then instead of manually generating the
>>            lower level code,
>>> it'll be turned into LLVM IR so that any platform that
>>            supports LLVM
>>> will have an easier time implementing new features,
>>            fixes, etc..
>>            I was hoping f18 would lower to something akin to clang's
>>            AST.
>>            Obviously clang's AST doesn't directly apply to Fortran
>>            but perhaps some
>>            kind of common interface could exist so that clang tools
>>            could work with
>>            Fortran codes. It would be great to have things like the
>>            clang static
>>            analyzer and clang-doc for Fortran.
>>            Some tools will be language-specific of course but it
>>            seems like Fortran
>>            and C-family languages share enough common concepts that
>>            some tooling
>>            could work with both, given a common interface.
>>            Language-specific tools
>>            would work with a more language-specific interface.
>>            My impression from the presentation is that there's a lot
>>            more that
>>            could be shared with clang. The messaging system and
>>            command-line
>>            options infrastructure should be shareable, for example.
>>            Maybe there's
>>            already work being done in these areas to make f18 a
>>            first-class LLVM
>>            project.
>>            I do find it concerning that there's almost no discussion
>>            about f18 on
>>            this list. Where is that discussion happening?
>>            -David
>>            _______________________________________________
>>            flang-dev mailing list
>>            flang-dev at lists.flang-compiler.org
>>            http://lists.flang-compiler.org/mailman/listinfo/flang-dev_
>>            lists.flang-compiler.org
>>        -- 
>>        Roger Ferrer Ibáñez
>>        _______________________________________________
>>        flang-dev mailing list
>>        flang-dev at lists.flang-compiler.org
>>        http://lists.flang-compiler.org/mailman/listinfo/flang-dev_lists.
>>        flang-compiler.org
>>    -- 
>>    Jeff Hammond
>>    jeff.science at gmail.com
>>    http://jeffhammond.github.io/
>>    _______________________________________________
>>    flang-dev mailing list
>>    flang-dev at lists.flang-compiler.org
>>    http://lists.flang-compiler.org/mailman/listinfo/flang-dev_lists.flang-
>>    compiler.org
>> _______________________________________________
>> flang-dev mailing list
>> flang-dev at lists.flang-compiler.org
>> http://lists.flang-compiler.org/mailman/listinfo/flang-dev_lists.flang-compiler.org

More information about the flang-dev mailing list