[flang-dev] [EXTERNAL] RFC: Upstreaming fir-dev in small chunks of functionality

Steve Scalpone via flang-dev flang-dev at lists.llvm.org
Mon Aug 10 16:52:19 PDT 2020


Hi David,

What's the benefit of forking llvm-project from fir-dev?

- Steve

On 8/7/20, 11:41 AM, "flang-dev on behalf of McCormick, Pat via flang-dev" <flang-dev-bounces at lists.llvm.org on behalf of flang-dev at lists.llvm.org> wrote:

    External email: Use caution opening links or attachments


    Thanks David.

    While I haven’t looked at your patches yet, I’m in favor of the direction that your approach takes. Specifically, I agree in terms of allowing for a more progressive path towards getting the code upstreamed and having a coordinated integration with testing plans that can proceed in parallel (vs. waiting for upstreaming to complete).  If coordinated with testing pieces that should help from a code coverage perspective — I worry other paths are more difficult in terms of building the supporting testing infrastructure and also represent a challenge for people who could be helping to flush out the testing.

    I’m not familiar with the nuances of the code here but this could also allow for more engagement across the community as the pieces are connected up in a more complete code generation path that would allow more effort towards integration of new features where codegen paths are currently blocked.  For example, would this simplify aspects of getting OpenMP, OpenACC, etc. integrated with aspects of FIR in a similar fashion (smaller steps with enabled testing along the way, getting a better look at integration across the components, etc.)?

    Thanks again,

    —Pat


    > On Aug 7, 2020, at 3:23 AM, David Truby via flang-dev <flang-dev at lists.llvm.org> wrote:
    >
    > Hi all,
    >
    > I've just posted a few patches to Phabricator to start a conversaton on
    > another way forward for upstreaming from fir-dev. What I'm trying to do
    > with these patches is upstream small chunks of codegen functionality
    > with the ability to end to end test the functionality being upstreamed.
    > To that end I've added here only enough code to codegen empty
    > subroutines and empty programs, and added lit tests for Fortran->FIR,
    > FIR->LLVM and Fortran->LLVM.
    >
    > I've split the patches in 3 parts, one to add the relevant code to the
    > tco tool to allow us to lower subroutines to LLVM IR, one to add (a
    > stripped down version of) the bbc tool and one to add lowering from PFT
    > to fir. You can find these patches here:
    > https://reviews.llvm.org/D85508
    > https://reviews.llvm.org/D85509
    > https://reviews.llvm.org/D85510
    >
    > These patches could then be built on with other patches adding
    > functionality in similar chunks (e.g. a possible next step would be to
    > add handling of functions with single return statements).
    >
    > I've tried not to diverge from fir-dev much when moving code over,
    > however in some places I have omitted classes and hand-inlined their
    > functions where only 1 or 2 simple functions are called in the
    > subroutine code generation in order to keep the diff small. Eventually
    > (if we follow this path) when we come to add more functionality those
    > classes would be added back in.
    >
    > What do people think of upstreaming in this way? Is this a possible way
    > for us to get the upstreaming process moving forward?
    >
    > Thanks!
    > David Truby
    > _______________________________________________
    > flang-dev mailing list
    > flang-dev at lists.llvm.org
    > https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev

    _______________________________________________
    flang-dev mailing list
    flang-dev at lists.llvm.org
    https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev



More information about the flang-dev mailing list