[flang-dev] Moving F18 closer to LLVM

[Doerfert, Johannes via flang-dev]

Thanks for this list!

Maybe we should have it somewhere, e.g., on phab or GH so people can see
the current status.

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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/flang-dev/attachments/20200115/536fdbe4/attachment.sig>