Support LLVM 16

[Baltoli]

LLVM 16 was released a few weeks ago and is already the default version for Homebrew. We should test the LLVM backend to make sure that it can be built with version 16; if not we need to update documentation pointing to Homebrew formulae to reflect this.

Running with version 16 in CI is blocked until the Nix maintainers ship it properly; work appears to already be ongoing here. We should nevertheless still check macOS informally.

• Homebrew formula page: https://formulae.brew.sh/formula/llvm#default
• Nixpkgs PR: llvmPackages_16: init NixOS/nixpkgs#223282

Things that need to be changed:

• Uses of getInstList on a basic block
• getABITypeAlign[ment]
• Invocation of opt

[RaitoBezarius]

FWIW, LLVM16 will (hopefully) be part of NixOS 23.05 and land in unstable soon.

[Baltoli]

Thanks @RaitoBezarius - that's helpful to know!

[Baltoli]

@theo25 to investigate the use of opaque pointers in this version

[theo25]

I looked into the release notes of LLVM 16 and it does not seem that the use of opaque pointers is mandated by this release. However, the release notes found in the main branch on github do list the opaque pointer change, so we can assume that the change is coming with the LLVM 17 release.

[Baltoli]

The Opaque Pointers migration document reveals that their introduction is not mandatory in LLVM 16, but they are enabled by default and the old system is no longer supported. This suggests that the LLVM 16 transition is the right point at which to make sure they work properly for the LLVM backend.

Some debugging reveals that there is a subtle issue we have previously missed when migrating over to opaque pointers. In transparent mode, we make equality comparisons between pointer types:

llvm-backend/lib/codegen/EmitConfigParser.cpp

Lines 852 to 854 in 046b596

	if (arg->getType() == ChildPtr->getType()) {
	arg = new llvm::LoadInst(arg_ty, arg, "", CaseBlock);
	}

These comparisons have their semantics changed silently when moving to opaque pointers. Previously, we'd have seen a comparison of A* == B* (with meaningful semantics depending on the pointee types A, B). However, now both sides of the comparison are now ptr and the comparison is silently failing. We need to audit the codebase for places where we're comparing pointer types in this way and fix them (similarly to previous changes) to compare the underlying types in a meaningful way.

[Baltoli]

This is possibly a tricky change, and so we should also update the documentation for macOS to reflect the fact that we don't yet support LLVM 16. Otherwise, we'll get breakages there for people building from source.

[dwightguth]

Ahhh. This is a good catch. This relates to how we are passing map, list, and set terms around at the llvm bytecode level. I don't remember the exact details. I can dig into it and try and refresh my memory if you'd like.

[dwightguth]

I believe that it was meant to only evaluate to true in the case involving map and map*, list and list*, and set and set* though, which is a comparison that could still be made with opaque pointers. The fix might be as simple as just wrapping each of these clauses in a guard against the sort category in question.

[Baltoli]

I did a quick dig into the code and that's the same conclusion I came to before seeing your comment. A grep suggests there are only a few places that we do it, so I will try making the change to check the sort category explicitly rather than relying on the pointer types and see how far that gets me. Thanks!

[dwightguth]

I mean, you would probably still need to check the types, but if you guard that check by only checking on the map, list, and set sort categories, I don't think it will actually break if you're using opaque pointers because it's checking whether one type is a pointer and the other is a struct.

[Baltoli]

Yep - my first pass attempt at a solution here leaves an invalid term somewhere in the configuration so we're still generating something with incorrect semantics wrt. opaque pointers. I'll try again with your comment there for pointer / struct types and see if that gets us further.

[Baltoli]

Still broken for opaque pointer reasons; need to update the documentation for MacOS etc. to make sure users stay on version 15.