Support llvm stable releases

[sbc100]

Historically emscripten has been built around always using the very latest upstream version of LLVM. Essentially it depends on the top-of-tree version.

However, for the purposes of packaging, reducing install and download size, and making emscripten more portable, it would be nice to start being compatible with the stable version of LLVM.

We have have had many requests for this feature of the years (e.g. #11313)

This would mean more testing since each emscripten release would need to be tested fully against both LLVM stable and LLVM tot. For this reason it probably makes sense to make this move once we fully remove fastcomp (#11319).

The downside is that we will need to add version checks in the emscripten codebase when it depends on new/tot features.

I suggest that we perhaps give this a try starting with LLVM 11. E.g. we support LLVM 11 and tot until LLVM 12 is releases and which point we support LLVM 12 + tot..

[tlively]

What will we do when a feature changes to be incompatible with the stable version of LLVM? Should we error out? Have a branch to handle both the old and new behaviors? I guess for unstable features that are changing frequently in upstream LLVM we can just error out eagerly if the LLVM version is not the one we test with.

[kripken]

Alternatively, we could refer people that want to use llvm 11 release to a specific emscripten version that is known to work with that? I.e. if they want to use an LLVM from the past, they can do so with the emscripten from the same time in the past.

[sbc100]

If we take that alternative approach I still think it would be nice to test against the actual release versions, rather than just the nearest emscripten release to the release revision.

[sbc100]

What will we do when a feature changes to be incompatible with the stable version of LLVM? Should we error out? Have a branch to handle both the old and new behaviors? I guess for unstable features that are changing frequently in upstream LLVM we can just error out eagerly if the LLVM version is not the one we test with.

I'm imagining there will be some places in emscripten where we need to do:

if LLVM_STABLE:
   error_out
else:
   use_new_feature

Nut hopefully they should be fairly few and far between. The frequency of these divergences should tell is fairly quickly if the approach is a sensible one.

Initially I think the testing burden will be the biggest obstacle we face.

[sbc100]

Looks like its happening now: #11637

What do you all think about trying to support 11.0 and 12.0 going forward?

[kripken]

I think if have the CI resources to also test 11 stable, it makes sense to experiment with this. But I think it should be an experiment we are ok with stopping, since it may become too hard to be worthwhile, like if we start to need lots of ifs for what LLVM version is used, as mentioned earlier.

[sbc100]

One advantage to testing against 11, once it is stable, is that we don't need to build our own versions of LLVM to test it.. we can just use the official binaries.

I suggest we try to find a sensible subset of tests to run against llvm 11.. perhaps monitoring the areas where we requires 12 and ensuring the subset includes those areas.

[kripken]

I'm worried about picking a subset, if we want to claim we support those binaries officially (do we?). Maybe we can check them less frequently or something, though?

[sbc100]

I would imagine that as long its only run a subset of tests we would not claim full support.

Once we ditch fastcomp and can do more testing I think it might be worth increasing the level of testing and officially supporting stable llvm. But I'm not suggesting that now.. .so maybe we should still have some kind of warning message about the lack of full support?

[sbc100]

Perhaps we can add this to the FYI bot along with the contrib ports tree?

[kripken]

Last two comments sgtm (not claim full support, use the FYI bot).