Supporting LLVM 16

[ivanperez-keera]

The debian team is looking into including IKOS into main. (I've requested that we request a change of license, to Apache License 2.0, to make that possible.)

A first challenge they've found is that the next Debian release will likely remove LLVM 14 and 15.

This is not urgent (the release will come out in 2025), but I don't know how much effort it would entail to support a new version of LLVM, specifically from 14 to 16.

I assume the changes to the IR are what could affect IKOS the most. Looking at LLVM 15's release notes, I find the following changes to the IR:

• LLVM now uses opaque pointers. This means that different pointer types like i8*, i32* or void()** are now represented as a single ptr type. See the linked document for migration instructions.

• Renamed llvm.experimental.vector.extract intrinsic to llvm.vector.extract.

• Renamed llvm.experimental.vector.insert intrinsic to llvm.vector.insert.

• The constant expression variants of the following instructions have been removed: extractvalue, insertvalue, udiv, sdiv, urem, srem, fadd, fsub, fmul, fdiv, frem.

• Added the support for fmax and fmin in atomicrmw instruction. The comparison is expected to match the behavior of llvm.maxnum.* and llvm.minnum.* respectively.

• callbr instructions no longer use blockaddress arguments for labels. Instead, label constraints starting with ! refer directly to entries in the callbr indirect destination list.

LLVM 16 includes the following changes to the IR:

• The readnone, readonly, writeonly, argmemonly, inaccessiblememonly and inaccessiblemem_or_argmemonly function attributes have been replaced by a single memory(...) attribute.

• The constant expression variants of the following instructions has been removed: fneg

• Target extension types have been added, which allow targets to have types that need to be preserved through the optimizer, but otherwise are not introspectable by target-independent optimizations.

• Added uinc_wrap and udec_wrap operations to atomicrmw.

• Renamed llvm.flt.rounds intrinsic to llvm.get.rounding.

[ivanperez-keera]

We have a need to revisit this because we want to support LLVM 16.

It sounds to me that all changes should be trivial except maybe the fact that "LLVM now uses opaque pointers. This means that different pointer types like i8*, i32* or void()** are now represented as a single ptr type. See the linked document for migration instructions."

@arthaud do you agree with that assessment?

How hard do you think it would be to support LLVM 16?

Thanks a lot!

[arthaud]

I'm just guessing but I think opaque pointers should be fine, we can introduce our own AR opaque pointer type to represent those. I assume you can't read from an opaque pointer and you have to cast it to a non-opaque type before.