Why is the Auto-Scheduler not generating vectorized loops in print_loop_nest()?

[jiasss]

I am experimenting with Halide's Auto-Scheduler. When I use func.print_loop_nest() to inspect the generated schedule, I notice that it only prints standard loop nests but completely lacks any vectorization (vectorized ...) or parallelization (parallel ...) annotations, even though the target hardware supports SIMD.

I want to know if this is expected behavior, an issue with print_loop_nest()'s reporting under auto-scheduling, or if my auto-scheduler configuration is missing something.

Here is my full Generator implementation:

#include <Halide.h>

class ExampleGenerator : public Halide::Generator<ExampleGenerator>{

    constexpr static int kSize = 1024;

    Halide::Var x{"x"}, y{"y"};
public:
    Input<Halide::Buffer<float, 2>> input{"input"}; 
    Output<Halide::Buffer<float, 2>> output{"output"};

    void generate() {

        const Func clamped = Halide::BoundaryConditions::repeat_edge(input);

        const RDom r(-1, 3, -1, 3);
        const Func blur {"blur"};
        blur(x, y) = 0.f;
        blur(x, y) += clamped(x + r.x, y + r.y);
        output(x, y) = blur(x, y) / 9.f;
    }

    void schedule() {
        if (!using_autoscheduler()) {
            output.compute_root()
                .vectorize(x, 8)
                .parallel(y, 8);
        }
        else {
            input.dim(0).set_estimate(0, kSize);
            input.dim(1).set_estimate(0, kSize);
            output.set_estimate(x, 0, kSize);
            output.set_estimate(y, 0, kSize);
        }
        output.print_loop_nest();
    }
};

HALIDE_REGISTER_GENERATOR(ExampleGenerator, example_generator)

Case 1: Manual Scheduling
The output correctly shows parallel and vectorized annotations as expected:

produce output:
  parallel y.y:
    for y.v3 in [0, 7]:
      for x.x:
        vectorized x.v2 in [0, 7]:
          produce blur:
            blur(...) = ...
            for r10 in [-1, 1]:
              for r10 in [-1, 1]:
                blur(...) = ...
          consume blur:
            output(...) = ...

Case 2: Auto-Scheduling (using Adams2019)
The output completely lacks any optimization annotations, showing only the raw, baseline loop nest:

produce output:
  for y:
    for x:
      produce blur:
        blur(...) = ...
        for r10 in [-1, 1]:
          for r10 in [-1, 1]:
            blur(...) = ...
      consume blur:
        output(...) = ...

Environment:

• Halide Version: v21.0.0
• OS: Windows 10

[abadams]

That's odd. Does the .stmt output show vectorization and parallelization?

[abadams]

Ah, right, and schedule() has to be called before the autoscheduler runs because that's where you set the estimates.

[jiasss]

I have checked both the generated .stmt and .html files. When using the auto-scheduler, I cannot find any loops related to vectorization or parallelization in the lowered IR (they remain as scalar loops). However, when switching to manual scheduling, the vectorized and parallelized loops appear correctly in the generated files.

It seems that the auto-scheduler's decisions are not being applied or triggered properly during this compilation flow, even though the estimates and target are set. Any insights on why the auto-scheduler might be bypassing these optimizations here?

[jiasss]

here is how I saved the files inside the generator:

Halide::Pipeline p = this->get_pipeline();
const Halide::Target target = Halide::get_host_target();
p.compile_to_lowered_stmt(
    "debug_pipeline.html",
    p.infer_arguments(),
    Halide::HTML,
    target
);
p.compile_to_lowered_stmt(
    "debug_pipeline.stmt",
    p.infer_arguments(),
    Halide::Text,
    target
);

[alexreinking]

That's still too early when using a generator. You need to ask for stmt/stmt_html as extra outputs. At the command line for the generator executable, thats the -e flag.

[jiasss]

Thank you! I successfully verified the solution via the command line, and the generated .stmt file now correctly includes the expected optimization details (parallelism, vectorization, etc.).

However, my project relies on CMake for the build system. We are currently using add_halide_generator and add_halide_library from Halide's CMake tools to manage the pipeline.

Could you please advise on how to properly pass the -e stmt,stmt_html flags and configure the autoscheduler options within these specific CMake macros?

[alexreinking]

Sure, here are the docs for the Halide CMake package:

https://github.com/halide/Halide/blob/main/doc%2FHalideCMakePackage.md

The arguments to add_halide_library you're interested in are the extra-output arguments. They're named after the output and take one argument: the name of a variable to populate with the path to the eventual output.

For example:

add_halide_library(
    MyPipeline
    FROM MyGenerator
    STMT_HTML pipleine_html_file
)

message(STATUS "During the build, the .stmt.html file for MyPipeline will be written to ${pipeline_html_file}")

[jiasss]

Thank you so much! I followed your guidance and successfully verified the solution via the command line. The generated .stmt file now correctly includes all the expected optimization details.

Now that the core optimization is working, I have a quick follow-up question regarding the CMake integration:

Is there an idiomatic way to customize the output directory for the generated C++ header files (.h) within the CMake macros? Currently, the headers are emitted into the build directory alongside the static libraries, and we have to manually copy them to our project's target include/ directory.

Does Halide's CMake tooling support an option or property to redirect the header output location directly, or is writing a custom CMake copy command the expected approach here?

Thanks again for your invaluable help!

[alexreinking]

Is there an idiomatic way to customize the output directory for the generated C++ header files (.h) within the CMake macros? Currently, the headers are emitted into the build directory alongside the static libraries, and we have to manually copy them to our project's target include/ directory.

Right now, that's true of all outputs because of how the GenGen tooling works. Everything goes to the same directory.

Does Halide's CMake tooling support an option or property to redirect the header output location directly, or is writing a custom CMake copy command the expected approach here?

It doesn't at the moment. You could add a custom command to copy it (use cmake -E copy_if_different), sure. We just haven't needed this functionality yet.

This is valuable feedback and I think it would make for a nice feature request. Please open an issue!

Thanks again for your invaluable help!

You're so welcome!