Skip to content

Llvm19 - #71

Closed
RedrockerLi wants to merge 3 commits into
tancheng:masterfrom
RedrockerLi:llvm19
Closed

RedrockerLi wants to merge 3 commits into
tancheng:masterfrom
RedrockerLi:llvm19

Conversation

@RedrockerLi

Copy link
Copy Markdown

No description provided.

LLVM 19's headers need std::is_class_v / std::is_pointer_v / std::optional / std::size.  Under C++14 the build produced 3418 errors, every one of them from inside /usr/lib/llvm-19/include/ rather than from this project.  Raising the standard takes that to zero; llvm-config-19 --cxxflags also emits -std=c++17.
The legacy pass manager API still COMPILES against LLVM 19: Debian's package
still ships llvm/Pass.h, so FunctionPass, RegisterPass<>, getAnalysisUsage
and getAnalysis<LoopInfoWrapperPass>() all build unchanged.  What is gone is
the INVOCATION -- `opt-19 -load x.so -mapperPass kernel.bc` fails with "The
`opt -passname` syntax for the new pass manager is not supported, please use
`opt -passes=<pipeline>`".  So the pass must be registered and invoked
through a pipeline even though the old headers would still let it build.

Converted mechanically:
  FunctionPass                  -> PassInfoMixin<mapperPass>
  runOnFunction(Function&)      -> run(Function&, FunctionAnalysisManager&)
  RegisterPass<mapperPass> X    -> llvmGetPassPluginInfo + parsing callback
  getAnalysis<LoopInfoWrap...>  -> FAM.getResult<LoopAnalysis>(F)

Two things worth knowing before rebasing this:

* The LoopInfo was fetched from a HELPER (getTargetLoops), not from the pass
  entry point, so the analysis result is threaded in as a new parameter
  rather than looked up in place.

* Only run()'s returns change, and they become PreservedAnalyses::all() --
  the pass only READS the IR (it builds its own DFG/CGRA model and writes
  JSON), which is what the legacy `return false` plus setPreservesAll()
  meant.  canMap(), a helper that genuinely returns bool, keeps its
  `return true;` / `return false;`.  run() and canMap() end adjacently in
  the file, so conflating them is easy; it compiles right up until the
  return type is checked.

Also disambiguates `json`: including llvm/Passes/PassBuilder.h transitively
pulls in llvm/Support/JSON.h, which declares llvm::json, so under the file's
`using namespace llvm` a bare `json` collides with `using json =
nlohmann::json`.  The alias is dropped and the four uses are spelled
nlohmann::json.

Verified: builds clean against LLVM 19.1.7; the .so registers and runs
(traced with -debug-pass-manager); on the FIR kernel it emits dfg.json and
config.json, and the simulator's CGRACtrl parses the latter.  See PORT.md.
Records why this branch exists, the exact three changes, the two silent
upstream footguns (-O0 marks functions optnone so the new pass manager skips
the pass entirely; -O3 alone fuses the MAC into llvm.fmuladd.f32 which no FU
implements and mapping fails), the verified invocation, and what the ported
build reproduces against the vendored golden config.

Also records what the port did NOT need: Mapper.cpp, DFG.cpp, DFGNode.cpp,
CGRA.cpp, CGRANode.cpp, CGRALink.cpp and all headers compile unmodified,
because the codebase keeps LLVM at arm's length and uses no typed-pointer
API anywhere -- so LLVM 15's opaque-pointer migration, normally the
expensive part of a port like this, is a non-issue here.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant