Installation fixes

[compor]

This PR is based on issues that came upon a "clean" Ubuntu 21.10 Docker image:

• Update the prerequisites list and the README file for this.

• Fix use of base path (--base-path commandline option) used for:

  • Utility scripts installation
  • Makefile template generation

  This allows installation of the Popcorn compiler without having to use the repo's top dir as the CWD.
  Ideally, the --base-path value should be autodetected, but I had no time to make this happen.

  • Add hunk to LLVM 9 patch that triggers a failed compilation due to a missing standard header inclusion (#include <limits>). This is part of the benchmarking code of the project, thus inconsequential for the core Popcorn compiler.

[compor]

@xjtuwxg this is not urgent, but a look into it would be appreciated :)

[xjtuwxg]

Thanks for the pull request. Seems like you want to upgrade the building script to a later Ubuntu version. Do you also have an update on the Dockerfile? Here is a link how to use it. Also, should we choose an LTS Ubuntu version like 20.04 or 22.04 as the base docker image?

I'm having a quick test using your script on a Ubuntu 20.04 base docker image, there seem a lot of warnings during the building process of LLVM/Clang9 (where 18.04 has a perfect building process w/o warnings). But I understand we cannot use the 18.04 docker image forever.

[compor]

Hey @xjtuwxg, thanks for the comments. All your suggestions make sense, so here is the actionable breakdown:

• [x] Update Dockerfile using a recent Ubuntu LTS version.
• [x] Fix build warnings emitted by GCC 11.2.0.
  • [x] The majority of the build warnings are related to the use of llvm::ArrayRef, e.g.:

    warning: initializing ‘llvm::ArrayRef<const llvm::SCEV*>::Data’ from ‘std::initializer_list<const llvm::SCEV*>::begin’ does not extend the lifetime of the underlying array [-Winit-list-lifetime]

  • [x] Other warnings have to do with move semantics, e.g.: warning: redundant move in return statement [-Wredundant-move] warning: moving a local object in a return statement prevents copy elision [-Wpessimizing-move]

Regarding the warnings, I think this is due to a newer GCC version which probably has improved checks for the code quality. I cannot guarantee a timeline for this, since I'm a bit busy this period, so I'd suggest leaving this PR open and I'll ping you to have another look once I address the above points.

[compor]

Hi again @xjtuwxg,

As per above, here's a more refined breakdown:

• Update Dockerfile to current Ubuntu LTS version 22.04 (Jammy)
• Breakdown for warnings emitted by GCC 11.2 and 11.3:
  • range-loop-construct: This warns that a ranged-for loop copy constructs each element per iteration, e.g. for(auto e: mylist) instead of for(const auto &e: mylist). These are issues with the LLVM codebase which have been fixed in newer releases like this. Hence, this warning is left to be emitted.
  • init-list-lifetime: This is a major contributor to the warning spam (over 1000 warnings). However, this is entirely related to how the ArrayRef API is used in LLVM. In a lengthy discussion regarding this issue on Phabricator, it was decided to disable the warning just for that use. Thus, a newer LLVM release should avoid emitting this warning. For now, we disable the warning.
  • deprecated-copy: This means that according to recent C++ standard conventions when if either copy ctro, operator= or a destructor is explicitly provided, then all 3 must be explicitly provided.
    This is fixed in newer LLVM releases by adding the missing methods as in this file.
    This warning is currently silenced as it emits a lot of warning spam.
  • deprecated-declarations: This is triggered when a deprecated API is used. The main culprit here is the use of mallinfo instead of the newer mallinfo2, as also documented elsewhere. This warning has been left to be emitted.
  • redundant-move: This is also something that depends on the LLVM codebase regarding NRVO. Having checked source locations that emit this up to LLVM's current development branch, some have been elided while others are still around. For now, we disable the warning.

Let me know what you think. Maybe the extra CMake CXX flags in e8bbb2bebcb5fd2f2a85505f7489013c06133489 for the aforementioned warnings could be guarded by a version check, e.g., to revisit them if the LLVM is greater than 9.1. Not sure if that is something desirable in this project.