[flang-dev] Moving F18 closer to LLVM

Richard Barton via flang-dev flang-dev at lists.llvm.org
Fri Jan 24 08:13:57 PST 2020 

Hi all



David is getting the permissions to capture all this in a github project on llvm-project, meanwhile let me try and pull together the status of the upstreaming work.



Reminder of the goal: a set of changes that make F18 more LLVM-like before submission to monorepo and a plan towards achieving that. Further LLVMification can continue in the monorepo.



  1.  CMake changes to support in-tree building:
     *   Pat is preparing a PR for submission
  2.  Style changes that take us closer to LLVM
     *   Clang format changes to bring F18 more in line with LLVM

                                                               i.      David has opened a PR here https://github.com/flang-compiler/f18/pull/945 and discussion is ongoing.

     *   Rationalisation of public/private headers

                                                               i.      David has opened up a PR https://github.com/flang-compiler/f18/pull/943 and discussion is ongoing.

     *   Renaming of files from .cc to .cpp

                                                               i.      Still TODO

  1.  Making more general use of LLVM APIs and datastructures
     *   This discussion needs to be started to agree on an initial list. David will start this off next week.
  2.  Port testing to use lit and FileCheck
     *   We have agreement on a way forward and Luke has opened up a PR https://github.com/flang-compiler/f18/pull/941 to port the test suite to lit.
     *   We will discuss separately the future of each of the various custom scripts.

                                                               i.      Frontrunner for test_errors.sh is to implement a flang --verify mode, but no firm conclusion yet.

                                                             ii.      No discussions yet on the others

                                                           iii.      Luke is going to investigate each script in turn.

  1.  Build compiler support
     *   Steve is going to kick off a thread with details of what Nvidia are building internally.
     *   Next step is to improve public buildbot coverage of this. Plan will be needed.



Thanks

Rich

From: flang-dev <flang-dev-bounces at lists.llvm.org> On Behalf Of David Truby via flang-dev
Sent: 20 January, 2020 21:04
To: Doerfert, Johannes <jdoerfert at anl.gov>
Cc: flang-dev at lists.llvm.org
Subject: Re: [flang-dev] Moving F18 closer to LLVM

I think I could make the page if I had commit access to llvm, which I don't. Do you know how I go about getting that or should I get someone else to do it?

Thanks
David Truby

Get Outlook for Android<https://aka.ms/ghei36>
________________________________
From: Doerfert, Johannes <jdoerfert at anl.gov<mailto:jdoerfert at anl.gov>>
Sent: Monday, January 20, 2020 9:02:46 PM
To: David Truby <David.Truby at arm.com<mailto:David.Truby at arm.com>>
Cc: flang-dev at lists.llvm.org<mailto:flang-dev at lists.llvm.org> <flang-dev at lists.llvm.org<mailto:flang-dev at lists.llvm.org>>
Subject: Re: [flang-dev] Moving F18 closer to LLVM

I agree. we should have a flang project there anyway, tracking high level things there seems reasonable to me. Can you create such a page or so ppl need special permissions?
--
written from my phone

________________________________
From: David Truby <David.Truby at arm.com<mailto:David.Truby at arm.com>>
Sent: Monday, January 20, 2020 10:42:11 AM
To: Doerfert, Johannes <jdoerfert at anl.gov<mailto:jdoerfert at anl.gov>>
Cc: flang-dev at lists.llvm.org<mailto:flang-dev at lists.llvm.org> <flang-dev at lists.llvm.org<mailto:flang-dev at lists.llvm.org>>
Subject: Re: [flang-dev] Moving F18 closer to LLVM

Hi Johannes,

Somehow it completely slipped my mind that LLVM has a GitHub organization now!
GitHub has a "project board" feature that you can use to track things like this, you can see the one we're using for tracking OpenMP semantic checking here:
https://github.com/orgs/flang-compiler/projects/1

This might be a good way of tracking progress on this, what do you think?

David Truby

________________________________
From: Doerfert, Johannes <jdoerfert at anl.gov<mailto:jdoerfert at anl.gov>>
Sent: 20 January 2020 20:24
To: David Truby <David.Truby at arm.com<mailto:David.Truby at arm.com>>
Cc: flang-dev at lists.llvm.org<mailto:flang-dev at lists.llvm.org> <flang-dev at lists.llvm.org<mailto:flang-dev at lists.llvm.org>>
Subject: Re: [flang-dev] Moving F18 closer to LLVM

I've seen similar things just as diffs on phab before. The llvm gh might have some better options, I don't know GH that well.

--
written from my phone
________________________________
From: David Truby <David.Truby at arm.com<mailto:David.Truby at arm.com>>
Sent: Monday, January 20, 2020 3:26:22 AM
To: Doerfert, Johannes <jdoerfert at anl.gov<mailto:jdoerfert at anl.gov>>
Cc: flang-dev at lists.llvm.org<mailto:flang-dev at lists.llvm.org> <flang-dev at lists.llvm.org<mailto:flang-dev at lists.llvm.org>>
Subject: Re: [flang-dev] Moving F18 closer to LLVM

Hi Johannes,

> On 15 Jan 2020, at 18:53, Doerfert, Johannes <jdoerfert at anl.gov<mailto:jdoerfert at anl.gov>> wrote:
>
> Thanks for this list!
>
> Maybe we should have it somewhere, e.g., on phab or GH so people can see
> the current status.

This sounds like a good idea, does Phabricator have a “projects” section where we can store this information and show which items are in progress? If so we should set this up on there so it is visible to the LLVM community at large rather than keeping it inside the F18 GitHub.

Thanks
David Truby

> On 01/15, David Truby via flang-dev wrote:
>> If anyone wants to discuss any of these separately in more detail, feel free to start a new thread for discussion.
>>
>> CMake Integration
>> - I believe this is already done by Eric from PGI, and is on github in his FIR pull request.
>> Can this be split off and merged separately to speed things up?
>>
>> Change file handling to LLVM's file infrastructure
>> - Our current file handling infrastructure prevents building on non-Unix systems (e.g. Windows), and duplicating file handling across two sub-projects is unnecessary.
>> - LLVM's file handling works slightly differently to F18's current infrastructure, however I believe F18 doesn't use file handling in many places so once the necessary changes have been worked out once it should not take long to change it in every instance.
>> - A possible alternative would be to change F18's file handling to use LLVM internally but expose the same public interface. I consider this a less ideal but easier to implement solution.
>>
>> Change uses of <iostream> to LLVM's streams
>> - For a number of reasons, LLVM has its own stream infrastructure to replace the standard streams.
>> LLVM's streams are a drop in replacement for standard streams (modulo type signatures) so this
>> should be a fairly simple change.
>>
>> Remove Flang custom data structures that can be replaced with LLVM equivalents
>> - This part is more open ended, as there are a lot of LLVM data structures that could be used with varying
>>  amounts of code change necessary.
>> - Below is a list of structures I have thought of so far:
>>       • std::string → StringRef where appropriate
>>       • EnumSet → llvm:PackedVector (not sure if this is directly comparable)
>>       • std::vector → llvm::SmallVector where appropriate
>>       • CharBuf → llvm::MemoryBuffer (not sure if this is directly comparable)
>>       • std::set → llvm::SmallSet/llvm::StringSet/llvm::DenseSet where appropriate
>>       • std::map → llvm::StringMap/llvm::DenseMap where appropriate
>>       • std::list → Something else everywhere it's used. LLVM discourages the use of std::list as there's almost always a better choice!
>>
>> Use llvm's error handling mechanisms
>> - Switch any unreachable cases to use llvm_unreachable with an error message. Does F18 have its own unreachable
>> Macro already? If so we can probably just search and replace for that.
>> - Use llvm::Error instead of error codes if and when error codes are used.
>>
>>
>> Please let me know if you think of anything else
>
> (A lot of these have been listed elsewhere already)
>
> File and folder names:
> - Capital starting letter
> - cc -> cpp
> - More expressive names, e.g., filenames: https://github.com/flang-compiler/f18/blob/master/lib/common/template.h,
>   the "bridges", ...
> - public headers (.h moved to https://github.com/flang-compiler/f18/tree/master/include/flang/ from https://github.com/flang-compiler/f18/tree/master/lib/common)
>
> Coding style:
> - doxygen style comments and file comments
> - single statement braces
> - early exits
> - no else after return
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/flang-dev/attachments/20200124/00d44a80/attachment-0001.html>

More information about the flang-dev mailing list