how to use halide generate c code ?

[leoluopy]

as the tile has mentioned .
how to use halide generate c code ?
i want to re implement the method mentioned by https://www.es.ele.tue.nl/~rjordans/downloads/vocke2017taco.pdf which describe a way to integrate DSP backend into halide by c code generation .
any one has some idea ?

[vksnk]

There is an example app, which demonstrates how to use C backend. Basically, the generator has an option of emitting a C++ code, which you can then compile and link into your application.

BTW, this might be of interest to you, we use a similar approach to generating a C++ code for one of the DSP in this branch

[leoluopy]

thanks . and if it's able to generate c++ code of xtensa DSP , is there a option to switch to generate c code for xtensa DSP . in our case , generating c code is preferred , looking forward to your reply .

[leoluopy]

@vksnk
hi , thanks for your reply , i am really interested at xtensa-codegen branch , is there any guide for me to config xtensa tool chain and compile a xtensa architecture executable .

[vksnk]

Currently, there is no option to generate a plain C code for Xtensa DSP (and for C++ we require at least C++11, maybe even C++14; that being said Xtensa toolchain can handle that without any issues).

For the xtensa-codegen branch, we currently support Q7 and Q8 DSPs. You'll need to add "xtensa" to your target string (by default for Q7; for Q8 add "xtensa_q8" on top of that), then generate C++ code using the standard approach. If you added xtensa-related features to your target string then generated code will be C++ with Xtensa DSP intrinsics, which you can compile and link to your application using toolchain from Cadence.

[leoluopy]

@vksnk
thanks , and how to add "xtensa" to my target string , right now i am using Q7. here's my demo project's CMakeLists :

cmake_minimum_required(VERSION 3.22)
project(c_backend)

enable_testing()

#Set up language settings
#set(CMAKE_CXX_STANDARD 17)
#set(CMAKE_CXX_STANDARD_REQUIRED YES)
#set(CMAKE_CXX_EXTENSIONS NO)

#Find Halide
find_package(Halide REQUIRED)

#Generator(s)
add_halide_generator(pipelinexxx.generator SOURCES le15.cpp)

add_halide_library(pipeline_le15 FROM pipelinexxx.generator
#C_BACKEND
XTENSA
GENERATOR my_first_generator)
add_halide_library(pipeline_le15_native FROM pipelinexxx.generator
GENERATOR my_first_generator)

#Final executable(s)
add_executable(le15 run.cpp)
target_link_libraries(le15
PRIVATE
pipeline_le15_native
pipeline_le15
)

and then there's a cmake Warning :
-- Building utils enabled
CMake Warning (dev) at cmake/HalideGeneratorHelpers.cmake:224 (message):
Arguments to add_halide_library were not recognized: XTENSA
Call Stack (most recent call first):

then i reviewed the generated code . this's no Xtensa DSP intrinsics .
any idea ? what's wrong with my cmake list ?

[leoluopy]

@vksnk
any suggestions ?

[vksnk]

Sorry, I don't use CMake that often, so might be incorrect, but I think the right way to do it is:

add_halide_library(pipeline_le15 FROM pipelinexxx.generator
C_BACKEND
TARGETS host
FEATURES xtensa
GENERATOR my_first_generator
)

If you haven't seen it yet, there is a very good description for using CMake with Halide: https://github.com/halide/Halide/blob/main/README_cmake.md

[vksnk]

Sorry, I thought I posted the answer, but apparently forgot to press comment button.

[leoluopy]

@vksnk
thanks for replying and it really works , the xtensa code has been successfully generated , and my xt-clang compiler only support c++ 11 , so how to use Cmake to set generated code to only has c++11 features .
now my cmakelist is like below , i have tried to set c++11 flag , but it failed .

cmake_minimum_required(VERSION 3.22)
project(c_backend)

enable_testing()

set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_STANDARD_REQUIRED YES)
set(CMAKE_CXX_EXTENSIONS NO)

find_package(Halide REQUIRED)

include_directories("/home/algo_share/projects/peiyuanluo/workspace/Halide/cmake-build-debug/apps/c_le1")
include_directories("/opt/Cadence_EDA_Tools/Xtensa_DSP_Q7/XtDevTools/install/builds/RI-2021.7-linux/dsp_base648229_1108/xtensa-elf/arch/include/")

add_halide_generator(pipelinexxx.generator SOURCES le15.cpp)
add_halide_library(pipeline_le15 FROM pipelinexxx.generator
C_BACKEND
TARGETS host
FEATURES xtensa
GENERATOR my_first_generator)
add_halide_library(pipeline_le15_native FROM pipelinexxx.generator
GENERATOR my_first_generator)

#add_library(le15_dbg /home/algo_share/projects/peiyuanluo/workspace/Halide/cmake-build-debug/apps/c_le1/pipeline_le15.halide_generated.cpp)

add_executable(le15 run.cpp)

target_link_libraries(le15
PRIVATE
pipeline_le15_native
pipeline_le15
le15_dbg
)

any suggestions ? look forward to your reply .

[leoluopy]

i got it from https://github.com/halide/Halide/blob/main/README_cmake.md , halide support at least c++17 .

[vksnk]

Unfortunately, there is no way to limit generated code to c++11. It's possible that generated code is still compilable with c++11 though, but I think in general c++14 or later might be needed (unless I am confusing something, @steven-johnson might know the best). Are you getting errors when you try to compile?

[steven-johnson]

Unfortunately, there is no way to limit generated code to c++11.

Well, there's currently no way to do so. It's likely we could limit generated code to C++11 with some work, but I don't know how much work would be involved. I don't think anyone on the Halide team is likely to work on this anytime soon (if ever) but we'd consider PRs that do this.

[leoluopy]

@steven-johnson
hi , actually , we prefer to use pure c generation to work at xtensa vision Q7 DSP in consideration of resource limitation . it's really appreciated , if it's supported in the future .

[steven-johnson]

The Halide team has no plans to convert the codegen to plain C.

If someone would like to take this on as a contributor project, they are welcome to do so, but be aware that it will be a nontrivial task.

[steven-johnson]

hi , actually , we prefer to use pure c generation to work at xtensa vision Q7 DSP in consideration of resource limitation .

Can you expand a bit on why you feel that "pure C" would produce meaningfully better code than the C++ we currently generate? (This is a serious question -- I am deeply skeptical that there would indeed be a meaningful improvement, but I would be quite interested to hear evidence to the contrary.)

[leoluopy]

well ,it's related to our SOC project . we develop this SOC project to do neural network inference . there are some many operators need to be implemented by xtensa dsp . in order to make it run faster , we want it always to being in the sram , so now the size of the operator is really critical , we found that while xtensa operator is based to c , it's size is always 20~80k . but while it is base to c++ , it's size is always 200K to several M , ie operator size is 2M or 4M or 8M . then if we use c++ operator , our SOC chip resource can not load as much operators as we can .

[leoluopy]

@steven-johnson
will it be difficult to add pure C codegen to Halide as a contibutor project . is there any guide or some TODO descriptions for making such a contribution project . i mean how to implement pure c code gen to match Halide canonical .

[leoluopy]

now i am using Halide to generate xtensa feature code , then use xtensa tool chain to compile it . all code is based to c++ 17. then the tool chain shows me some error:
pipeline_le15.halide_generated.cpp:5448: undefined reference to halide_error_buffer_argument_is_null' /opt/Cadence_EDA_Tools/Xtensa_DSP_Q7/XtDevTools/install/tools/RI-2021.7-linux/XtensaTools/bin/xt-ld: /home/leo/Downloads/tt7/tmp/pipeline_le15.halide_generated.cpp:5456: undefined reference to halide_error_buffer_argument_is_null'
/opt/Cadence_EDA_Tools/Xtensa_DSP_Q7/XtDevTools/install/tools/RI-2021.7-linux/XtensaTools/bin/xt-ld: /home/leo/Downloads/tt7/tmp/pipeline_le15.halide_generated.cpp:5532: undefined reference to halide_error_bad_type' /opt/Cadence_EDA_Tools/Xtensa_DSP_Q7/XtDevTools/install/tools/RI-2021.7-linux/XtensaTools/bin/xt-ld: /home/leo/Downloads/tt7/tmp/pipeline_le15.halide_generated.cpp:5538: undefined reference to halide_error_bad_dimensions'
/opt/Cadence_EDA_Tools/Xtensa_DSP_Q7/XtDevTools/install/tools/RI-2021.7-linux/XtensaTools/bin/xt-ld: /home/leo/Downloads/tt7/tmp/pipeline_le15.halide_generated.cpp:5546: undefined reference to halide_error_bad_type' /opt/Cadence_EDA_Tools/Xtensa_DSP_Q7/XtDevTools/install/tools/RI-2021.7-linux/XtensaTools/bin/xt-ld: /home/leo/Downloads/tt7/tmp/pipeline_le15.halide_generated.cpp:5552: undefined reference to halide_error_bad_dimensions'

it seems that i need more halide related source code to fix this error . and on the other hand , if i am generating pure C_BACKEND code , there's another library libpipeline_le15_native.a which i need to link it into my final executable . but as i am to generate a xtensa c++ code , i am using xtensa tool chain to compile the generated code , so may be i need the source code of libpipeline_le15_native.a ?
any idea ?
@steven-johnson
@vksnk

[vksnk]

will it be difficult to add pure C codegen to Halide as a contibutor project . is there any guide or some TODO descriptions for making > such a contribution project . i mean how to implement pure c code gen to match Halide canonical .

I guess you can take a look at how CodeGen_C.cpp and CodeGen_Xtensa.cpp are implemented and do something similar, but with generating C instead of C++.

Re linker errors:

Right, you need to link in corresponding parts of runtime. I think if you link in files listed here https://github.com/halide/Halide/blob/xtensa-codegen/Makefile#L2410 this should be sufficient (sorry for the extra steps, this is still WIP).

[zvookin]

We're really not interested in supporting a pure C backend. It sounds like there is a code size issue that should be largely resolvable by careful choice of flags to the C++ compiler. C++ code that doesn't use various features and does not import unnecessary libraries should be very close to the same size as the same functionality in C.

C++11 is likely worth preserving.

[leoluopy]

@zvookin
yes , code size is the real concern , thanks for replying , if your team has any plan or any update , please let me know , our team should really interested at using the new feature .

[steven-johnson]

As mentioned before, we don't really have any plan in this update, nor are the current core contributors likely to add one anytime soon.

If you (or any other contributors) wanted to focus on ways to improve the code size of the existing backend (e.g. by tweaking patterns that might improve codegen, or by figuring out the optimal set of compiler / linker flags to minimize tool-generated overhead), we'd very much welcome PRs in that area.

[leoluopy]

@steven-johnson
sure thanks , by now , is there any guide for reduce the size of generated code ? or i need to changing the code of CodeGen_Xtensa.cpp ?

[leoluopy]

some examples about figuring out the optimal set of compiler / linker flags ?

[steven-johnson]

Sorry, I don't have any suggestions.

[leoluopy]

@steven-johnson @vksnk @zvookin
hi , good news , i have successfully generated c++ 17 xtensa feature code , and compile it by xtensa tool chain , then simulated the executable at Xplore . every thing is fine . now my generator code is below , then i have a question : how to add a dma copy function to the generator ?

#include "Halide.h"
#include <stdio.h>

using namespace Halide;

// Generators are a more structured way to do ahead-of-time
// compilation of Halide pipelines. Instead of writing an int main()
// with an ad-hoc command-line interface like we did in lesson 10, we
// define a class that inherits from Halide::Generator.
class MyFirstGenerator : public Halide::Generator {
public:
// We declare the Inputs to the Halide pipeline as public
// member variables. They'll appear in the signature of our generated
// function in the same order as we declare them.
Input<uint8_t> offset{"offset"};
Input<Buffer<uint8_t, 2>> input{"input"};

// We also declare the Outputs as public member variables.
Output<Buffer<uint8_t, 2>> brighter{"brighter"};

// Typically you declare your Vars at this scope as well, so that
// they can be used in any helper methods you add later.
Var x, y;

// We then define a method that constructs and return the Halide
// pipeline:
void generate() {
    // In lesson 10, here is where we called
    // Func::compile_to_file. In a Generator, we just need to
    // define the Output(s) representing the output of the pipeline.
    brighter(x, y) = input(x, y) + offset;

    // Schedule it.
    brighter.vectorize(x, 64);
}

};

// We compile this file along with tools/GenGen.cpp. That file defines
// an "int main(...)" that provides the command-line interface to use
// your generator class. We need to tell that code about our
// generator. We do this like so:
HALIDE_REGISTER_GENERATOR(MyFirstGenerator, my_first_generator)

ie. now my generator code has only the vectorization feature , how to add the dma feature into that ? as you know , compuation in sram(xmem) is much faster .

[leoluopy]

@steven-johnson @vksnk @zvookin
any suggestions about how to use dma in generator ?