[flang-dev] Moving F18 closer to LLVM

[Finkel, Hal J. via flang-dev]

On 1/15/20 7:15 AM, David Truby via flang-dev wrote:
> Hi all,
>
> Anyone that has been following the upstreaming discussion on llvm-dev will know that F18 has been under some (fair)
> scrutiny with regards to its integration with LLVM and lack of use of LLVM data structures.
> Richard Barton has asked me to look at this so I’ve made a cursory list of things that we should consider changing to
> bring us closer to the rest of the LLVM project. If anyone has any additional suggestions please let me know.
>
> 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!


Thanks, David!

Something that Chris Lattner pointed out off list: 
https://github.com/flang-compiler/f18/blob/master/lib/common/bit-population-count.h 
should be replaced by the corresponding LLVM utility functions.

  -Hal


>
> 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
>
> Thanks
> David Truby
> _______________________________________________
> flang-dev mailing list
> flang-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory