[qt/clang/llvm]: Summary of bulk changes made

KDE Git Services - Bulk Change <[email protected]>
Newsgroups gmane.comp.kde.cvs
Message-ID <[email protected]>
Git repository change summary for qt/clang/llvm
Pushed by mirror-service into branch 'upstream/users/vchuravy/hlfir-pipeline-plugin-example'.
Changed from 0000000000000000000000000000000000000000 to 4e51478f4397689a74bca7e24f6708a1791df26f
Acknowledgement was received that this change introduces only existing code that has been pushed to another public open source repository.

This change contains the following new commits:

Git commit 47fffa41d619850f2770c56037e0ae2af235375c by Valentin Churavy on 27/07/2026 at 08:19..
[flang] Add HLFIR-to-FIR pass pipeline extension points

The FIR optimizer extension points (FIROptEarly, FIRInliner, FIROptLast) all
run after HLFIR has been lowered to FIR, so the HLFIR intrinsic operations
(hlfir.sum, hlfir.matmul, ...) are gone by the time they run. Transformations
that need to see those operations -- for example automatic differentiation via
Enzyme-MLIR -- have nowhere to attach.

Add two extension points to createHLFIRToFIRPassPipeline:

  * HLFIROptEarly, at the start of the pipeline, before any HLFIR
    simplification or inlining.
  * HLFIROptLast, just before createLowerHLFIRIntrinsics.

Drivers register passes through registerHLFIROptEarlyEPCallbacks and
registerHLFIROptLastEPCallbacks on MLIRToLLVMPassPipelineConfig. The invoke
methods are const so they can be called on the const config the HLFIR pipeline
receives. With no callbacks registered the pipeline is unchanged.

The tests assert on printAsTextualPipeline output rather than just on the
callbacks firing, so that a reordering of the pipeline breaks them, and cover
every optimization level.

Co-Authored-By: Claude Opus 5 <[email protected]>
https://invent.kde.org/qt/clang/llvm/-/commit/47fffa41d619850f2770c56037e0ae2af235375c

Git commit c827a8ca5a22dbf6bd1753eaddf728dc7b01559f by Valentin Churavy on 27/07/2026 at 08:20..
[flang] Add a pass-pipeline config-augmentor hook for -load'ed plugins

The HLFIR-to-FIR pass pipeline exposes extension points on
MLIRToLLVMPassPipelineConfig, but that config is built inside the frontend, so
a -load'ed plugin has no way to reach it and register passes.
registerDefaultInlinerPass is the only augmentor today, and it is wired in by
hand.

Add a global registry of config augmentors:

  * fir::registerPassPipelineConfigCallback(cb) appends a callback, to be
    called from a plugin's static initializer at -load time.
  * fir::invokePassPipelineConfigCallbacks(config) runs them on the config.

This mirrors what flang already does for -load'ed plugin actions via
FrontendPluginRegistry: a process-global, append-only registry populated from
static initializers, which run before any compilation begins.

Both code generation entry points invoke the callbacks after building their
config and before constructing the pipeline: CodeGenAction::lowerHLFIRToFIR,
which serves -emit-fir, and CodeGenAction::generateLLVMIR, which serves
-emit-llvm/-emit-obj and reaches createHLFIRToFIRPassPipeline through
createMLIRToLLVMPassPipeline. The two are mutually exclusive for a given
compilation, so the callbacks run exactly once either way and a plugin gets the
same behaviour whichever output the user asked for.

No-op unless a callback is registered; tools that build the same pipelines
without consulting the registry (bbc, tco) are unaffected.

Co-Authored-By: Claude Opus 5 <[email protected]>
https://invent.kde.org/qt/clang/llvm/-/commit/c827a8ca5a22dbf6bd1753eaddf728dc7b01559f

Git commit 4e51478f4397689a74bca7e24f6708a1791df26f by Valentin Churavy on 27/07/2026 at 08:20..
[flang] Add an example plugin exercising the HLFIR pipeline extension points

The HLFIR extension points, the config augmentor registry and fir-opt's symbol
export exist to let an out-of-tree MLIR pass run while the HLFIR intrinsic
operations (hlfir.sum, hlfir.matmul, ...) are still present. None of that was
covered end to end, and there was no worked example of how to use it.

Add flang/examples/HLFIRPipelinePlugin, modelled on PrintFlangFunctionNames. It
contributes a pass that prints the HLFIR operations still present in the
module, tagged with the pipeline position it was inserted at, and exposes it
through both plugin entry points: a static initializer calling
fir::registerPassPipelineConfigCallback for the `flang -fc1 -load` path, and
mlirGetPassPluginInfo so fir-opt can load it with --load-pass-plugin.

Nothing is linked into the shared object: MLIR, FIR and flang symbols resolve
against the host tool, which is what export_executable_symbols_for_plugins on
flang and fir-opt provides. Removing the fir-opt export drops it from ~105k
exported dynamic symbols to one and makes --load-pass-plugin fail to load.

Two tests use it. Examples/hlfir-pipeline-plugin.f90 covers -emit-fir and
-emit-llvm, plus a no-plugin negative check; at -O0 the intrinsics reach both
extension points, while at -O2 SimplifyHLFIRIntrinsics has expanded them before
the Last one, which is why both exist. Examples/fir-opt-pass-plugin.fir covers
--load-pass-plugin and the pass showing up in fir-opt's registry.

Co-Authored-By: Claude Opus 5 <[email protected]>
https://invent.kde.org/qt/clang/llvm/-/commit/4e51478f4397689a74bca7e24f6708a1791df26f
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.