[flang-dev] Moving F18 closer to LLVM
Doerfert, Johannes via flang-dev
flang-dev at lists.llvm.org
Wed Jan 15 10:53:50 PST 2020
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)
- doxygen style comments and file comments
- single statement braces
- early exits
- no else after return
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 228 bytes
Desc: not available
More information about the flang-dev