[flang-dev] Moving F18 closer to LLVM

[David Truby via flang-dev]

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>
Sent: 20 January 2020 20:24
To: David Truby <David.Truby at arm.com>
Cc: flang-dev at lists.llvm.org <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>
Sent: Monday, January 20, 2020 3:26:22 AM
To: Doerfert, Johannes <jdoerfert at anl.gov>
Cc: flang-dev at lists.llvm.org <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> 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/20200120/75421fa6/attachment-0001.html>