1. 13 Feb, 2020 3 commits
  2. 12 Dec, 2019 1 commit
  3. 06 Sep, 2019 2 commits
  4. 05 Sep, 2019 5 commits
    • Hans-Nikolai Viessmann's avatar
      Fix up usage text · d6eb0397
      Hans-Nikolai Viessmann authored
      d6eb0397
    • Hans-Nikolai Viessmann's avatar
      add -generic flag to sac2c · 8497c5ef
      Hans-Nikolai Viessmann authored
      We have had issues with the build system using mtune=native to compile
      the libsac2c and the runtime libraries, making it impossible to create
      distributable packages without it breaking due to ISA incompatibilities.
      
      Changing the build system to not use mtune=native is doable, but
      involves having to filter out the mtune=native flag at the right points
      in the build. Additionally, when using different C compilers (such as
      with NVCC) we need to account for this, which may require a different
      solution for each compiler. This is non-trivial to achieve as in some
      instances the compiler is not applicable to build sac2c, but only a
      runtime lib or two.
      
      This commit uses a different method, which encodes the mtune=native flag
      into sac2crc and adds a sac2c flag (`-generic`) to toggle the effect.
      The advantage here is that we can define different flags for different
      SBIs, without affecting the build system. Furthermore, the changes to
      the build system are minimal, which involves propagating the flags to
      sac2crc and change whether libsac2c is built with mtune=native or not.
      8497c5ef
    • Artem Shinkarov's avatar
      Properly porapagate BUILDGENERIC into runtime libraries. · cf03b0da
      Artem Shinkarov authored and Hans-Nikolai Viessmann's avatar Hans-Nikolai Viessmann committed
      
      
          Previously we didn't compile runtime libraries like libsac,
          sacprelude, etc. with -mtune=generic.  As a consequence, all our
          packages are (very likely) incompatible with cpus other than
          of the host system.
      
          This commit fixes it.
      Signed-off-by: Hans-Nikolai Viessmann's avatarHans-Nikolai Viessmann <hv15@hw.ac.uk>
      cf03b0da
    • Hans-Nikolai Viessmann's avatar
      Merge branch 'hans-develop' into 'develop' · 96b2c3c6
      Hans-Nikolai Viessmann authored
      remove -pedantic flag from cmake
      
      See merge request !110
      96b2c3c6
    • Hans-Nikolai Viessmann's avatar
      disable pedantic warnings for the argcount header · 9dceb0e8
      Hans-Nikolai Viessmann authored
      We make use of a GCC system header marker to indicate that the
      headerfile is not C standard compliant, and thus disable the warnings
      relating to zero-argument variadic macros.
      
      This commit also fixes a small mistake in config.cmake where we added
      the no warning flag to the wrong var (oops).
      9dceb0e8
  5. 23 Apr, 2019 1 commit
  6. 20 Apr, 2019 1 commit
  7. 19 Apr, 2019 2 commits
    • Hans-Nikolai Viessmann's avatar
      fix spurious CMake build problem · fd1eb007
      Hans-Nikolai Viessmann authored
      This is a known issue with running a CMake built Makefile system
      that eventually calls and External_Project. The various _steps_ in
      the External_Project are **not** considered individual jobs with
      interdependencies. This can therefor cause multiple instances of one
      _step_ to be run, leading to undefined behavior. The issue is
      documented in [1] and affects all versions of CMake > 3.10.
      
      The workaround for this is to explicitly set dependencies on the _steps_
      and remove DEPENDS from the External_Project.
      
      [1]: https://gitlab.kitware.com/cmake/cmake/issues/18663
      fd1eb007
    • Hans-Nikolai Viessmann's avatar
      Fix missing includes · b6931c58
      Hans-Nikolai Viessmann authored
      b6931c58
  8. 18 Apr, 2019 3 commits
  9. 16 Apr, 2019 4 commits
  10. 09 Apr, 2019 1 commit
    • Hans-Nikolai Viessmann's avatar
      Fix incorrect traversal doflag check · 54490710
      Hans-Nikolai Viessmann authored
      Completely forgot that EMRL is one by default, therefore whenever we
      entered IWLMEM, we entered EMRTU, which in some very rare cases did
      cause problems. We now check that the EMRCI and EMRTU flag is on as well!
      54490710
  11. 08 Apr, 2019 1 commit
    • Hans-Nikolai Viessmann's avatar
      refactoring of EMRTU and IWLMEM · e0ecc1fc
      Hans-Nikolai Viessmann authored
      Have moved out a function used in both traversals to the cuda_utils
      module.
      
      Also, I've removed the ISEMRLIFTED flag from EMRL/EMRTU, as it was
      preventing certain cases from being identified (such as cond functions).
      e0ecc1fc
  12. 04 Apr, 2019 3 commits
    • Hans-Nikolai Viessmann's avatar
      284fc096
    • Hans-Nikolai Viessmann's avatar
      add EMRTU optimistation · 0db3f254
      Hans-Nikolai Viessmann authored
      This optimisation works together with the CUDA IWLMEM optimisation to introduce
      CUDA memory transfers into the AST. We need this traversal when using the EMR
      optimisation as IWLMEM would otherwise lead to inoptimal code generation.
      
      IWLMEM, when encountering a lift ERC, would within the loop function create a
      host2device and cause a memory allocation and free on the CUDA device. The
      EMRTU (EMR Type Update) traversal identifies such cases, and correclty
      transforms the lifted ERCs into CUDA device_types *and* fixes the arguments of
      the loop function applications (initial and recursi
      0db3f254
    • Hans-Nikolai Viessmann's avatar
      EMRL mark fundef has allocation lifts · c27c2728
      Hans-Nikolai Viessmann authored
      We will use this later for EMRTU (relating to CUDA IWLMEM
      optimisation).
      c27c2728
  13. 03 Apr, 2019 1 commit
  14. 02 Apr, 2019 1 commit
    • Hans-Nikolai Viessmann's avatar
      remove stale CUDA module · 9af256c3
      Hans-Nikolai Viessmann authored
      The insert_memory_transfers module was split into several different
      files (insert_withloop_memtran.c & insert_cudast_memtran.c) by Jing
      starting from the 26-03-2010, and this was left in the git history.
      
      This module is not used anywhere, and as far as I can tell, provides
      nothing in addition to the other modules. As such its safe to remove the
      files.
      
      Additionally, I've identified the following libsac2c modules which are
      also stale:
      
      icm_betest.c
      icm_trace.c
      icm_comment.c
      BEtest.c
      wl_empty_result_handling.c
      create_lac_fun.c
      wl_descalarization.c
      cuda_create_dfg.c
      idag.c
      elemqueue.c
      elemlist.c
      cygcompat.c
      cygwinhelpers.c
      
      One needs to take a closer look at this and see if they are still
      useful.
      9af256c3
  15. 28 Mar, 2019 2 commits
  16. 27 Mar, 2019 2 commits
  17. 21 Jan, 2019 1 commit
  18. 20 Jan, 2019 1 commit
  19. 11 Jan, 2019 1 commit
  20. 10 Jan, 2019 4 commits