Skip to content
GitLab Next
  • Menu
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • lfortran lfortran
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 432
    • Issues 432
    • List
    • Boards
    • Service Desk
    • Milestones
    • Requirements
  • Merge requests 72
    • Merge requests 72
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • lfortranlfortran
  • lfortranlfortran
  • Issues
  • #313
Closed
Open
Created Mar 31, 2021 by Ondřej Čertík@certikOwner88 of 102 checklist items completed88/102 checklist items

MVP: Roadmap to compile the SNAP project

The roadmap at #272 is a general roadmap. In this issue I am listing a specific roadmap to compile just one project:

https://github.com/lanl/SNAP

Once we can compile it, we can release an MVP (minimum viable product) of LFortran. This project is a great target for MVP because it is not written by me, thus this will be useful to people, it uses Fortran 95, it's about 8000 lines of code, and the MPI can be turned off, it is a proxy app for a bigger production code. It is within reach. To compile it, we do not need to implement Fortran features in all generality, just enough to compile SNAP.

Roadmap

Parsing and AST now works. We are now working on ASR, see below.

Parsing

There are only 4 small issues, otherwise LFortran can parse everything.

LFortran issues:

  • Label after cycle: #317 (closed)
  • More complicated generator expressions: #315 (closed)

SNAP seems to be using two extensions, which might be fixed in SNAP itself, or we can implement them in LFortran:

  • Missing comma after / in format specification (works in NAG, but seems not standard conforming): #314 (closed) (we fixed it in LFortran), https://github.com/lanl/SNAP/pull/13
  • Missing comma between strings in format specification (fails in the NAG compiler also): #316, https://github.com/lanl/SNAP/pull/17

AST

We can test that AST is correct file by file using lfortran fmt -i analyze.f90 which overwrites the file by going from AST to source code. At this point the LFortran master can translate all files to AST and back and the result compiles with gfortran and SNAP gives identical results. This ensures that there are no major bugs in the parser and the AST representation (there might still be some minor bugs where we got the right result by accident). Here are all the files sorted from the largest to the smallest:

  • setup.f90
  • thrd_comm.f90
  • input.f90
    • read (!821 (merged))
    • namelist declaration (!835 (merged))
  • mms.f90
  • mkba_sweep.f90
  • dim3_sweep.f90
    • continue (!836 (merged))
  • translv.f90
    • use inside subroutine (!828 (merged), !831 (merged))
    • implied do loop (!832 (merged))
  • output.f90
  • outer.f90
  • inner.f90
    • write/format
  • sweep.f90
  • plib.f90
    • interface (!808 (merged))
  • solvar.f90
    • allocate/deallocate (!807 (merged))
  • geom.f90
    • derived type in fmt (!825 (merged))
    • derived type access in expressions (!826 (merged))
  • snap_main.f90
    • write/format
  • dim1_sweep.f90
  • utils.f90
    • strings 'aa' // 'bb' incorrectly printed (!808 (merged))
    • write
    • open (!824 (merged))
    • close (!823 (merged))
  • octsweep.f90
  • sn.f90
    • allocate/deallocate (!807 (merged))
  • data.f90
    • allocate/deallocate (!807 (merged))
  • control.f90
    • allocate/deallocate statements (!807 (merged))
  • time.f90
    • write/format
  • expxs.f90
    • interface (!808 (merged))
  • analyze.f90
    • Dimension missing arguments (!806 (merged))
  • version.f90
    • write prints as print (!814 (merged), !815 (merged), !820 (merged), !822 (merged))
    • format statements are skipped (!809 (merged), !811 (merged), !812 (merged), !813 (merged))
  • dealloc.f90
  • global.f90

ASR

The goal is to compile each module to the modfile using lfortran -c global.f90 -o global.o. Here is the first full dependency tree, we can take it from top to bottom:

  • global.f90
    • Module save attribute (!884 (merged))
    • Intrinsic kind function, SELECTED_INT_KIND and SELECTED_REAL_KIND (!885 (merged), !888 (merged), !900 (merged))
  • version.o : global.o
    • Issues with loading the global module (!901 (merged), !902 (merged), !903 (merged), !904 (merged))
    • Allow to use module variables in use (!906 (merged))
    • Intrinsic subroutine DATE_AND_TIME
    • Intrinsic write
  • geom.o : global.o
  • sn.o : global.o
    • allocatable attribute for array declarations (module variable)
  • data.o : global.o
  • control.o : global.o
  • time.o : global.o
  • plib.o : global.o time.o
  • thrd_comm.o: global.o plib.o
  • expxs.o : global.o geom.o sn.o data.o
  • solvar.o : global.o plib.o geom.o sn.o data.o control.o
  • mms.o: global.o geom.o sn.o data.o control.o plib.o
    • Generic procedures from the plib module (#358 (closed))
    • "LFortranException: read_string: String is too short for deserialization", probably due to derived types
  • dealloc.o : global.o sn.o data.o mms.o geom.o solvar.o control.o
  • utils.o : global.o dealloc.o plib.o control.o
  • analyze.o: global.o control.o geom.o data.o solvar.o plib.o
  • input.o : global.o plib.o geom.o sn.o data.o control.o utils.o time.o
  • setup.o : global.o geom.o sn.o data.o control.o mms.o utils.o time.o plib.o
  • output.o : global.o geom.o sn.o data.o control.o utils.o solvar.o mms.o time.o plib.o
  • snap_main.o : global.o utils.o version.o input.o setup.o output.o time.o dealloc.o plib.o control.o
  • dim1_sweep.o : global.o geom.o sn.o data.o control.o plib.o
  • dim3_sweep.o : global.o plib.o geom.o sn.o data.o control.o thrd_comm.o
  • mkba_sweep.o : global.o plib.o geom.o sn.o data.o control.o thrd_comm.o
  • octsweep.o : global.o geom.o sn.o data.o control.o solvar.o thrd_comm.o dim1_sweep.o dim3_sweep.o mkba_sweep.o
  • sweep.o : global.o data.o geom.o sn.o control.o octsweep.o solvar.o plib.o thrd_comm.o
  • inner.o : global.o geom.o sn.o data.o control.o solvar.o sweep.o time.o plib.o thrd_comm.o
  • outer.o : global.o geom.o sn.o data.o solvar.o control.o inner.o time.o plib.o expxs.o thrd_comm.o
  • translv.o : global.o plib.o geom.o sn.o data.o control.o utils.o solvar.o expxs.o outer.o time.o thrd_comm.o analyze.o

Other issues to resolve:

  • Runtime library must be working

The LFortran and SNAP commits that together produce an ASR for snap_main.f90:

  • The latest master of LFortran (as of 93d2b868)
  • https://github.com/certik/SNAP/commit/c10d86d3c7970c0ff070360496797132fac0462f

Fortran features that were commented out in SNAP that we need to implement in LFortran:

  • format statement
  • do loops with no loop variable (just do / code / end do)
  • where statement
  • improve derived types: we have an initial implementation, but we need to improve it for SNAP
  • namelist
  • array initializer
  • case statement for strings
  • improve pointers: add nullify, fix bugs
  • improve open statement
  • runtime library functions: huge, all, mod, minloc, ceiling, maxloc, get_command_argument, adjustl, exit, date_and_time

The SNAP branch compiles with gfortran into an executable, and runs with an output:

$ ./gsnap 
 Aww SNAP. Program failed. Try again.

The parts that were commented out make the code not run correctly, but it "runs".

Backends

C++

The C++ backend (as of the latest master 93d2b868) generates the following code:

  • https://gist.github.com/certik/bbfbffd6a247adb22f2fb9bc3d7b3a77

It does not compile with a C++ compiler yet. This is our main effort now.

LLVM

Other issues

  • Figure out how to run a simple example without MPI: https://github.com/lanl/SNAP/issues/12, so that we can compare results against other Fortran compilers.
Edited Sep 03, 2021 by Ondřej Čertík
Assignee
Assign to
Time tracking