[CPU] Introduce optimization level to CPU backend. by hanhanW · Pull Request #23259 · iree-org/iree

hanhanW · 2026-01-23T02:06:52Z

The revision adds CPUCodegenOptions and moves few CPU flags to the struct:

iree-llvmcpu-disable-distribution: always default off.
iree-llvmcpu-fail-on-out-of-bounds-stack-allocation: always default on.
iree-llvmcpu-reassociate-fp-reductions: default off for O0, on for O2+
Merged a pass level test to pipeline test because disabling distribution is a global option.

Note that iree-opt-level is the master flag that also controls iree-llvmcpu-mlir-opt-level unless you explicitly specify a value.

The opt-level fix causes split_reduction_using_tiling.mlir to fail because FP reassociation is now correctly disabled at O0. The test validates that split reduction produces similar results to normal reduction - a relative tolerance (rtol 0.01%) is more appropriate than absolute tolerance since FP rounding error scales with value magnitude.

It is a step towards #19072

Assisted-by: Claude

The revision adds CodegenOptions (shared) and CPUCodegenOptions and moves few CPU flags to the struct: - iree-llvmcpu-disable-distribution - iree-llvmcpu-fail-on-out-of-bounds-stack-allocation - iree-llvmcpu-reassociate-fp-reductions It also introduces `iree-codegen-emit-performance-warnings` and uses it for a performance warning. The performance warning flag can also be used by software emulation warning if needed. It is a step towards iree-org#19072 Signed-off-by: hanhanW <[email protected]>

hanhanW · 2026-01-23T17:21:48Z

I did not enable binding, so I did not get the test failure. It is intended. I was wrong that I thought iree-opt-level overwrite other *-opt-level. Let me remove the test.

iree/compiler/bindings/python/test/api/api_test.py

Lines 62 to 66 in f816205

    
           session.set_flags("--iree-opt-level=O2") 
        
           flags = session.get_flags() 
        
           self.assertIn("--iree-opt-level=O2", flags) 
        
           self.assertIn("--iree-global-optimization-opt-level=O0", flags) 
        
           self.assertIn("--iree-opt-strip-assertions=false", flags)

IanWood1

Nice! I'm excited to see codegen options using the optimization level defaults.

My main feedback is about session compatibility. Currently, the pipeline uses CPUCodegenOptions::FromFlags::get(), which only accesses global CLI flags. This means when the compiler is invoked through a session (e.g., via C API), any flags set via session.setFlags() will be ignored. Only the initial global CLI flags will be used. Getting this working will also make it easier for other backends/plugins to implement similar options.

compiler/src/iree/compiler/Codegen/LLVMCPU/LLVMCPULowerExecutableTarget.cpp

IanWood1 · 2026-01-23T17:22:29Z

compiler/src/iree/compiler/Codegen/Utils/CodegenOptions.h

+  // Fail if the upper bound of dynamic stack allocation cannot be solved.
+  bool failOnOutOfBoundsStackAllocation = true;


This defaults to true but the PR description says:

iree-llvmcpu-fail-on-out-of-bounds-stack-allocation: always default off.

Looks like this was always default true, so maybe the description needs to be fixed?

Good catch, fixed the description. Thanks!

IanWood1 · 2026-01-23T19:17:21Z

compiler/src/iree/compiler/Codegen/Utils/CodegenOptions.cpp

+                   {init_at_opt(llvm::OptimizationLevel::O0, false),
+                    init_at_opt(llvm::OptimizationLevel::O1, true)},
+                   llvm::cl::desc("Enables reassociation for FP reductions."),
+                   llvm::cl::cat(category));


Should the iree-llvmcpu-* options be in the LLVMCPU dir?

Good question. Initially, I was planning to put each option to their own directories. However, I found that there is an option used by both LLVMCPU/ and ExternalInterfaces/, which determines whether scalable lowering should be enabled or not: clEnableScalableVectorization. I'm considering to expose this to public option.

The other point is that putting all the options together is less fragmented, IMO. So you can browse all the options for all the backends in a single file.

Thus, I ended up with having them altogether in this file; it is also easier to skim through all the options because they all locate in a single file. I think I should mention this in PR description. What do you think?

IanWood1 · 2026-01-23T19:21:24Z

compiler/bindings/python/test/api/api_test.py

+        def testCodegenOptLevelCascade(self):
+            # Set global opt level to O2, check cascade to codegen opt levels.
+            session = Session()
+            session.set_flags("--iree-opt-level=O2")
+            flags = session.get_flags()
+            self.assertIn("--iree-codegen-opt-level=O2", flags)
+            self.assertIn("--iree-llvmcpu-opt-level=O2", flags)
+
+        def testCodegenOptLevelOverride(self):
+            # Override just the CPU opt level, verify it doesn't affect others.
+            session = Session()
+            session.set_flags("--iree-opt-level=O2")
+            session.set_flags("--iree-llvmcpu-opt-level=O0")
+            flags = session.get_flags()
+            self.assertIn("--iree-codegen-opt-level=O2", flags)
+            self.assertIn("--iree-llvmcpu-opt-level=O0", flags)


The failure here is expected. If you look at testOptFlags() test above, --iree-global-optimization-opt-level and --iree-opt-strip-assertions are never modified. This test doesn't check that the options "cascade" but rather that they are not modified.

Also, it might be worth it to keep these to ensure that the code here is working correctly.

iree/compiler/src/iree/compiler/API/Internal/CompilerDriver.cpp

Lines 994 to 1001 in bc80992

if (!session.globalInit.usesCommandLine) {

session.binder.applyOptimizationDefaults();

}

auto resetDefaults = llvm::scope_exit([&]() {

if (!session.globalInit.usesCommandLine) {

session.binder.restoreOptimizationDefaults();

}

});

I updated the test which makes sure that one of the option is captured by sessions.

IanWood1 · 2026-01-23T20:05:17Z

compiler/src/iree/compiler/API/Internal/CompilerDriver.cpp

+  // Codegen options (inherit from global opt level).
+  // Note: Registration order matters for inheritance.
+  (void)CodegenOptions::FromFlags::get();
+  (void)CPUCodegenOptions::FromFlags::get();


I think we want to handle this in LLVMCPU's plugin registration. It should be possible to use the createUninitializedSession(OptionsBinder &localOptionsBinder) hook to bind the options. Then, we should be able to plumb through the options to the passes here:

iree/compiler/plugins/target/LLVMCPU/LLVMCPUTarget.cpp

Lines 865 to 870 in bc80992

void populateHALTargetBackends(IREE::HAL::TargetBackendList &targets) {

// #hal.executable.target<"llvm-cpu", ...

targets.add("llvm-cpu", [=]() {

return std::make_shared<LLVMCPUTargetBackend>(options.getTargetOptions());

});

}

This should be better because this will allow us to set the options per session.

IanWood1 · 2026-01-23T20:11:29Z

compiler/src/iree/compiler/Codegen/Common/MaterializeEncodingPatterns.cpp

+    if (CodegenOptions::FromFlags::get().emitPerformanceWarnings) {
+      loadOp.emitWarning("decomposing mismatched encoding load op");
+    }


This should be plumbed through as a member on the option & a pass option for the passes that use this pattern. The main reason is that FromFlags::get() doesn't work with sessions. But it also makes it easier to reproduce the warning if it's a pass option.

IanWood1 · 2026-01-23T20:13:20Z

compiler/src/iree/compiler/Codegen/LLVMCPU/KernelDispatch.cpp

  // Set all the distribution tile sizes to zero if thread distribution is
  // disabled.
-  if (clDisableDistribution) {
+  if (CPUCodegenOptions::FromFlags::get().disableDistribution) {


IanWood1 · 2026-01-23T20:18:26Z

compiler/src/iree/compiler/Codegen/LLVMCPU/LLVMCPULowerExecutableTarget.cpp

  LoweringConfigAttrInterface loweringConfig = getRootLoweringConfig(funcOp);
  auto pipeline = translationInfo.getDispatchLoweringPassPipeline();
  LLVMCPUPipelineOptions pipelineOpts;
+  pipelineOpts.cpuOpts = CPUCodegenOptions::FromFlags::get();


This should be a pass option, too. But it might be a bit trickier.

Signed-off-by: hanhanW <[email protected]>

hanhanW · 2026-01-26T22:46:11Z

I tested with a python program that ensures the distribution option is working as expected:

Compiling with distribution enabled...
Compiling with distribution disabled...

Running benchmarks...

With distribution (parallel):    9.48 ms
Without distribution (sequential): 202.56 ms
Speedup from distribution: 21.37x

hanhanW · 2026-01-26T22:53:31Z

compiler/plugins/target/LLVMCPU/LLVMCPUTarget.cpp

+
+  // Override Registration to also bind CPUCodegenOptions to the session.
+  struct Registration : PluginSession::Registration {
+    using PluginSession::Registration::Registration;


This using statement is required for

iree/compiler/src/iree/compiler/PluginAPI/Client.h

Lines 267 to 268 in 7edade7

auto registration =

std::make_unique<typename SessionTy::Registration>(std::move(pluginId));

… and MLIR Signed-off-by: hanhanW <[email protected]>

hanhanW · 2026-01-27T17:08:21Z

@IanWood1 I have a question. Why isn't iree-opt-level a master flag? E.g., I'd expect it sets default optimization level for sub-categories like global-opt, codegen, etc. Is it just not implemented yet, or it is intended?

(I'm mainly looking at this comment about having a master flag, i.e., iree-llvmcpu-opt-level, for CPU backend, but I think the iree-opt-level can serve the role?)

IanWood1

Looks good to me in terms of setting up the Binder/Options. However, I'm not familiar enough with this part of the codebase so I'll hold of on approving. One thing that I just noticed is that there already exists an options struct for LLVMCPU named LLVMCPUTargetCLOptions:

iree/compiler/plugins/target/LLVMCPU/LLVMTargetOptions.h

Line 174 in 7aa7be5

struct LLVMCPUTargetCLOptions {

Binder method:

iree/compiler/plugins/target/LLVMCPU/LLVMTargetOptions.cpp

Line 481 in 7aa7be5

void LLVMCPUTargetCLOptions::bindOptions(OptionsBinder &binder) {

Given this other struct exists, why do we need the new CPUCodegenOptions struct? This isn't blocking. I'm just trying to get an idea of whats going on.

compiler/src/iree/compiler/Codegen/LLVMCPU/Passes.cpp

IanWood1 · 2026-01-27T17:19:29Z

@IanWood1 I have a question. Why isn't iree-opt-level a master flag? E.g., I'd expect it sets default optimization level for sub-categories like global-opt, codegen, etc. Is it just not implemented yet, or it is intended?

(I'm mainly looking at this comment about having a master flag, i.e., iree-llvmcpu-opt-level, for CPU backend, but I think the iree-opt-level can serve the role?)

Maybe I'm misunderstanding what you mean by master flag but --iree-opt-level should work as a master flag. For example, if you set --iree-opt-level=O3 then --iree-global-optimization-opt-level will also get set to O3. Additionally, when you have a flag that is linked to the optimization level, it will get set based on the pipeline opt level. For example, --iree-opt-strip-assertions gets set when --iree-global-optimization-opt-level is >O0 (either through setting the global opt flag or the master --iree-opt-level flag).

https://github.com/iree-org/iree/blob/7aa7be5fd3f237f3ef885437f3d1be3f8798dac6/tools/test/compile_flags.mlir demonstrates this behavior.

hanhanW · 2026-01-27T17:25:20Z

Looks good to me in terms of setting up the Binder/Options. However, I'm not familiar enough with this part of the codebase so I'll hold of on approving. One thing that I just noticed is that there already exists an options struct for LLVMCPU named LLVMCPUTargetCLOptions:

iree/compiler/plugins/target/LLVMCPU/LLVMTargetOptions.h

Line 174 in 7aa7be5

struct LLVMCPUTargetCLOptions {

Binder method:

iree/compiler/plugins/target/LLVMCPU/LLVMTargetOptions.cpp

Line 481 in 7aa7be5

void LLVMCPUTargetCLOptions::bindOptions(OptionsBinder &binder) {

Given this other struct exists, why do we need the new CPUCodegenOptions struct? This isn't blocking. I'm just trying to get an idea of whats going on.

How the codegen works in IREE is that we have some lowering/transformation/optimization that takes linalg ops as input and lower them to low-level dialect. On CPU side, they are lowered to LLVM dialect; we conver them to LLVM module and rely on LLVM to do further lowering. Having a new option allows us to set different optimization level on MLIR lowering and LLVM lowering. This is why I'm adding a new option for MLIR part.

@IanWood1 I have a question. Why isn't iree-opt-level a master flag? E.g., I'd expect it sets default optimization level for sub-categories like global-opt, codegen, etc. Is it just not implemented yet, or it is intended?
(I'm mainly looking at this comment about having a master flag, i.e., iree-llvmcpu-opt-level, for CPU backend, but I think the iree-opt-level can serve the role?)

Maybe I'm misunderstanding what you mean by master flag but --iree-opt-level should work as a master flag. For example, if you set --iree-opt-level=O3 then --iree-global-optimization-opt-level will also get set to O3. Additionally, when you have a flag that is linked to the optimization level, it will get set based on the pipeline opt level. For example, --iree-opt-strip-assertions gets set when --iree-global-optimization-opt-level is >O0 (either through setting the global opt flag or the master --iree-opt-level flag).

https://github.com/iree-org/iree/blob/7aa7be5fd3f237f3ef885437f3d1be3f8798dac6/tools/test/compile_flags.mlir demonstrates this behavior.

I see, thanks for the sharing on lit tests which demonstrates that it is a master flag. I was confused by the api_test.py. I thought that the iree-global-optimization-opt-level flag was not set to O2 in this case. I may be misunderstanding about what this test is doing.

iree/compiler/bindings/python/test/api/api_test.py

Lines 62 to 66 in 7aa7be5

    
           session.set_flags("--iree-opt-level=O2") 
        
           flags = session.get_flags() 
        
           self.assertIn("--iree-opt-level=O2", flags) 
        
           self.assertIn("--iree-global-optimization-opt-level=O0", flags) 
        
           self.assertIn("--iree-opt-strip-assertions=false", flags)

Signed-off-by: hanhanW <[email protected]>

hanhanW

I found a "bug" that iree-opt-level does not work as master flag for iree-llvmcpu-mlir-opt-level. Claude helps me the fix: f1e7a09

Thus, we no longer need the change in docs/. The original suggestion includes iree-opt-level in the compile command.

Signed-off-by: hanhanW <[email protected]>

hanhanW · 2026-01-27T22:31:18Z

compiler/src/iree/compiler/Codegen/Utils/CodegenOptions.h

+  // Enables reassociation for FP reductions.
+  bool reassociateFpReductions = true;


I found the issue because this is set wrongly. After thinking a while, should we just drop all the default values from this struct? The real default values are defined in .cpp, IIUC.

Signed-off-by: hanhanW <[email protected]>

hanhanW · 2026-01-30T21:54:21Z

Looks good to me in terms of setting up the Binder/Options. However, I'm not familiar enough with this part of the codebase so I'll hold of on approving. One thing that I just noticed is that there already exists an options struct for LLVMCPU named LLVMCPUTargetCLOptions:

iree/compiler/plugins/target/LLVMCPU/LLVMTargetOptions.h

Line 174 in 7aa7be5

struct LLVMCPUTargetCLOptions {

Binder method:

iree/compiler/plugins/target/LLVMCPU/LLVMTargetOptions.cpp

Line 481 in 7aa7be5

void LLVMCPUTargetCLOptions::bindOptions(OptionsBinder &binder) {

Given this other struct exists, why do we need the new CPUCodegenOptions struct? This isn't blocking. I'm just trying to get an idea of whats going on.

How the codegen works in IREE is that we have some lowering/transformation/optimization that takes linalg ops as input and lower them to low-level dialect. On CPU side, they are lowered to LLVM dialect; we conver them to LLVM module and rely on LLVM to do further lowering. Having a new option allows us to set different optimization level on MLIR lowering and LLVM lowering. This is why I'm adding a new option for MLIR part.

Actually, there is a chance to have a single binder. We can declare a field for CPUCodegenOption in the old struct and reuse the binder. Let me give it a shot.

hanhanW · 2026-02-02T19:08:52Z

I gave it a shot, and I learned the setup better. If we move the CPUOptions into LLVMCPUTargetCLOptions and we reuse the binder, we will hit a dependency violation that core codegen will depend on plugin. Because the default value of CPUOptions in LLVMCPULowerExecutableTargetPass pass will be LLVMTargetOptions::FromFlags::get().cpuOpts. I think core (Codegen/LLVMCPU/) can't depend on plugin code (plugins/target/LLVMCPU/).

Thus, if we want to keep CPUOptions controled by global without the weird dependency, we'll need to the registeration separately, which leads to current situation.

Summary:

Option A (current state): Keep CPUCodegenOptions::FromFlags in core. Custom Registration needed to avoid double-registration. Global CLI works everywhere.
Option B: Remove FromFlags from CPUCodegenOptions. We will lose the global cli control at pass level, which makes logic disconnect.

@IanWood1 does it answer your question?

IanWood1

LGTM on setting up the binder with the plugin.

From the description:

The opt-level fix causes split_reduction_using_tiling.mlir to fail because FP reassociation is now correctly disabled at O0. The test validates that split reduction produces similar results to normal reduction - a relative tolerance (rtol 0.01%) is more appropriate than absolute tolerance since FP rounding error scales with value magnitude.

Do we have any way to test the binder is working correctly when >O0? It would be nice to have a test, but this might be a difficult thing to check.

compiler/src/iree/compiler/API/Internal/CompilerDriver.cpp

Signed-off-by: hanhanW <[email protected]>

hanhanW · 2026-02-03T00:51:20Z

LGTM on setting up the binder with the plugin.

From the description:

The opt-level fix causes split_reduction_using_tiling.mlir to fail because FP reassociation is now correctly disabled at O0. The test validates that split reduction produces similar results to normal reduction - a relative tolerance (rtol 0.01%) is more appropriate than absolute tolerance since FP rounding error scales with value magnitude.

Do we have any way to test the binder is working correctly when >O0? It would be nice to have a test, but this might be a difficult thing to check.

Good point! Tests are added in 3fb271b. Thanks that we have pipeline tests for split reduction flag.

MaheshRavishankar

I am approving this change. I highlighted one issue I found here with the use of std::optional but I cant suggest an alternative.

@benvanik if you have thoughts here please let us know.

MaheshRavishankar · 2026-02-04T18:34:50Z

compiler/src/iree/compiler/API/Internal/CompilerDriver.cpp

+  // opt-level-dependent defaults are applied before options are copied. The
+  // `std::optional` is required because PluginManagerSession does not have
+  // default constructor. Using `std::optional` allows deferring construction.
+  std::optional<PluginManagerSession> pluginSession;


The only issue I have with this PR is this std::optional thing. I cant suggest an alternative though cause I couldnt come up with a "cleaner" way of doing this.

I gave it another shot and it turns out that we don't need the optional. Because the constructor of pluginSession stores reference for PluginManagerOptions and it doesn't read the values, so the ordering does not matter here. It is safe as long as the values are not run until initializePlugins.

EDIT: I was wrong again, so reverted it back.

MaheshRavishankar · 2026-02-04T18:37:32Z

tests/e2e/regression/split_reduction_using_tiling.mlir

      linalg.yield %0 : f32
  } -> tensor<128xf32>
-  check.expect_almost_eq (%normal_reduce, %split_reduction, atol 0.1) : tensor<128xf32>
+  check.expect_almost_eq (%normal_reduce, %split_reduction, atol 0.0, rtol 0.0001) : tensor<128xf32>


atol of 0? really that is pretty stringent. I guess you turned off reassociation? Its good though if we can keep it this way.

rtol matters here. The default is zero, which is too small. The values are not small, so atol does not play a big role here.

hanhanW · 2026-02-05T01:59:45Z

I fixed a default value in 384b2e7, but it triggered bugs. Then I realized that the iree-opt-level never works with iree-opt unless we have bb0d837

@IanWood1 can you take a look?

Signed-off-by: hanhanW <[email protected]>

The revision adds CPUCodegenOptions and moves few CPU flags to the struct: - iree-llvmcpu-disable-distribution: always default `off`. - iree-llvmcpu-fail-on-out-of-bounds-stack-allocation: always default `on`. - iree-llvmcpu-reassociate-fp-reductions: default `off` for `O0`, `on` for `O2+` - Merged a pass level test to pipeline test because disabling distribution is a global option. Note that `iree-opt-level` is the master flag that also controls `iree-llvmcpu-mlir-opt-level` unless you explicitly specify a value. The opt-level fix causes split_reduction_using_tiling.mlir to fail because FP reassociation is now correctly disabled at O0. The test validates that split reduction produces similar results to normal reduction - a relative tolerance (rtol 0.01%) is more appropriate than absolute tolerance since FP rounding error scales with value magnitude. It is a step towards iree-org#19072 Assisted-by: Claude --------- Signed-off-by: hanhanW <[email protected]>

hanhanW requested review from MaheshRavishankar, Max191, benvanik and qedawkins as code owners January 23, 2026 02:06

This was referenced Jan 23, 2026

[Codegen] Add an option to enable fp8/fp4 software emulation for all GPU targets. #23238

Merged

[RFC] Formally supporting some suite of "-O*" type flags #19072

Open

hanhanW requested a review from IanWood1 January 23, 2026 02:10

IanWood1 reviewed Jan 23, 2026

View reviewed changes

hanhanW added 3 commits January 26, 2026 14:22

Plumb through session (address comments)

3d6acf5

Signed-off-by: hanhanW <[email protected]>

Fix naming

7e43748

Signed-off-by: hanhanW <[email protected]>

Update docs and switch default to O2 for fp reassociation optimization

65e65d3

Signed-off-by: hanhanW <[email protected]>

hanhanW requested a review from ScottTodd as a code owner January 26, 2026 22:37

hanhanW removed the request for review from ScottTodd January 26, 2026 22:37

tweak a bit

581c613

Signed-off-by: hanhanW <[email protected]>

hanhanW requested review from IanWood1 and removed request for Max191 and qedawkins January 26, 2026 22:41

hanhanW requested a review from bjacob January 26, 2026 22:46

hanhanW commented Jan 26, 2026

View reviewed changes

hanhanW changed the title ~~[Codegen] Introduce optimization level to Codegen.~~ [CPU] Introduce optimization level to CPU backend. Jan 27, 2026

hanhanW mentioned this pull request Jan 27, 2026

[GPU] Introduce and plumb through GPUCodegenOptions. #23290

Merged

Rename to iree-llvmcpu-mlir-opt-level to differentiate between LLVM…

476acea

… and MLIR Signed-off-by: hanhanW <[email protected]>

bjacob approved these changes Jan 27, 2026

View reviewed changes

IanWood1 reviewed Jan 27, 2026

View reviewed changes

compiler/src/iree/compiler/Codegen/LLVMCPU/Passes.cpp Outdated Show resolved Hide resolved

hanhanW added 2 commits January 27, 2026 14:13

Defers pluginSession construction until after applyOptimizationDefaults

f1e7a09

Signed-off-by: hanhanW <[email protected]>

Revert doc changes: iree-opt-level is the master flag

bae2dfc

Signed-off-by: hanhanW <[email protected]>

hanhanW requested a review from IanWood1 January 27, 2026 22:19

hanhanW commented Jan 27, 2026

View reviewed changes

Remove unnecessary code (address comments)

8d819e9

Signed-off-by: hanhanW <[email protected]>

hanhanW commented Jan 27, 2026

View reviewed changes

Switch to rtol

e3cb2ac

Signed-off-by: hanhanW <[email protected]>

hanhanW mentioned this pull request Feb 2, 2026

[DT] [SVE] specify vscale for wg count and storage size calculations #23023

Merged

IanWood1 approved these changes Feb 3, 2026

View reviewed changes

compiler/src/iree/compiler/API/Internal/CompilerDriver.cpp Show resolved Hide resolved

Add tests for split-reduction with optimization level flags.

3fb271b

Signed-off-by: hanhanW <[email protected]>

MaheshRavishankar approved these changes Feb 4, 2026

View reviewed changes

hanhanW enabled auto-merge (squash) February 4, 2026 22:14

hanhanW force-pushed the users/hanhanW/global-options branch from 880b83a to bb0d837 Compare February 5, 2026 01:57

hanhanW disabled auto-merge February 5, 2026 03:17

hanhanW added 5 commits February 5, 2026 15:03

Rename variable to make it clear.

e2b0fc0

Signed-off-by: hanhanW <[email protected]>

Fix default value, although it does not matter.

ae23a73

Signed-off-by: hanhanW <[email protected]>

Ensure GlobalPipelineOptions::FromFlags::get() for iree-opt.

d526829

Signed-off-by: hanhanW <[email protected]>

clang-format

a506b4b

Signed-off-by: hanhanW <[email protected]>

add missing dep

ab014d9

Signed-off-by: hanhanW <[email protected]>

hanhanW force-pushed the users/hanhanW/global-options branch from 391dcc1 to ab014d9 Compare February 5, 2026 23:15

hanhanW merged commit 1b75890 into iree-org:main Feb 6, 2026
54 of 57 checks passed

hanhanW deleted the users/hanhanW/global-options branch February 6, 2026 00:28

benvanik mentioned this pull request Feb 6, 2026

iree-compile/iree-opt crash on startup: DenseMap iterator invalidation in OptionsBinder::topLevelOpt #23411

Closed

		// Fail if the upper bound of dynamic stack allocation cannot be solved.
		bool failOnOutOfBoundsStackAllocation = true;

	if (!session.globalInit.usesCommandLine) {
	session.binder.applyOptimizationDefaults();
	}
	auto resetDefaults = llvm::scope_exit([&]() {
	if (!session.globalInit.usesCommandLine) {
	session.binder.restoreOptimizationDefaults();
	}
	});

	void populateHALTargetBackends(IREE::HAL::TargetBackendList &targets) {
	// #hal.executable.target<"llvm-cpu", ...
	targets.add("llvm-cpu", [=]() {
	return std::make_shared<LLVMCPUTargetBackend>(options.getTargetOptions());
	});
	}

	auto registration =
	std::make_unique<typename SessionTy::Registration>(std::move(pluginId));

		// Enables reassociation for FP reductions.
		bool reassociateFpReductions = true;

Conversation

hanhanW commented Jan 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hanhanW commented Jan 23, 2026

Uh oh!

IanWood1 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hanhanW commented Jan 26, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hanhanW commented Jan 27, 2026

Uh oh!

IanWood1 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

IanWood1 commented Jan 27, 2026

Uh oh!

hanhanW commented Jan 27, 2026

Uh oh!

hanhanW left a comment

Choose a reason for hiding this comment

Uh oh!

hanhanW Jan 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hanhanW commented Jan 30, 2026

Uh oh!

hanhanW commented Feb 2, 2026

Uh oh!

IanWood1 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

hanhanW commented Feb 3, 2026

Uh oh!

MaheshRavishankar left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hanhanW Feb 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hanhanW Feb 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

hanhanW commented Jan 23, 2026 •

edited

Loading

IanWood1 left a comment •

edited

Loading

hanhanW Jan 27, 2026 •

edited

Loading

hanhanW Feb 4, 2026 •

edited

Loading

hanhanW Feb 4, 2026 •

edited

Loading