Skip to content

Update to Newer LLVM Versions

Fabian Schiebel edited this page Mar 22, 2025 · 13 revisions

The Purpose of This Page

This page is intended to give PhASAR's users an easier time to follow LLVM updates. We try to keep up to date with LLVM's most recent stable version. Users of PhASAR are therefore also required to update their code.

In the following, we report on the major changes that we had to make to PhASAR to keep it compatible with the most recent LLVM version. This information should provide useful insights to users that also need to update their code base. LLVM's changelog can be found here: https://releases.llvm.org/download.html---check out the release notes for the respective version.

Update from LLVM-15 to LLVM-16

This looks like a smaller change compared to the previous LLVM update, and will probably mostly cause some minor changes in PhASAR. Still, unfortunately, our copy of LLVM's CFL alias analyses does not work with LLVM-16 anymore, as LLVM has done quite some cleanup in their alias analysis infrastructure. As our copy of LLVM's CFL alias analyses was meant as a workaround anyway, this is now the time to add an own alias analysis to PhASAR.

PhASAR's 26XX version(s) will probably have already upgraded to LLVM-16+.

Update from LLVM-14 to LLVM-15

In the transition from 14 to 15, LLVM removes the default support for typed pointer-types and from there on only supports opaque pointers (see Opaque Pointers) by default. Non-opaque pointers are deprecated.

As a consequence, PhASAR analyses can no longer assume that we can invoke getElementType() on a llvm::PointerType and getPointerElementType() from llvm::Type. Some analyses such as the IfdsFieldSensTaintAnalysis and a number of utilities (e.g. the DataFlowUtils) require pointer element types. These require larger transition within PhASAR which probably will result in breaking changes that you can follow here.

As that wasn't bad enough, LLVM additionally removes the CFL-based alias analysis implementations that PhASAR heavily relies on. We are already working on own standalone alias analyses within PhASAR in order to replace the CFLAndersAA and CFLSteensAA from LLVM.

There also have been some minor breaking changes, such as renaming dyn_cast_or_null to dyn_cast_if_present

UPDATE: We are now providing LLVM's CFL alias analyses as part of phasar as a workaround until we have an own solution.

UPDATE: We switched to LLVM 15 completely, which required some Breaking Changes.

Update from LLVM-11 to 12 to 13 to 14

There were no major changes

Update From LLVM-10 to LLVM-11

The most prominent API change involves the handling of call sites. Rather than analyzing call sites using the llvm::ImmutableCallSite type in code similar to what follows:

const llvm::Instruction *I = /* some instruction */;
if (llvm::isa<llvm::CallInst>(I) || llvm::isa<llvm::InvokeInst>(I)) {
  llvm::ImmutableCallSite CS(I);
  // analyze CS
}

users now have to use the llvm::CallBase type instead:

const llvm::Instruction *I = /* some instruction */;
if (const auto *CB = llvm::dyn_cast<llvm::CallBase>(I)) {
  // analyze CB
}

Please check https://llvm.org/doxygen/classllvm_1_1CallBase.html for details on llvm::CallBase.

Clone this wiki locally