Open Barabas5532 opened 7 months ago
0xjakob
commented
7 months ago @Barabas5532 Could you please specify the ESP-IDF version, the chip and gcc version which you are using? Furthermore, what is the compiler call used to generate this code (you can use idf.py -v build to see all compiler calls)?
Lapshin
commented
7 months ago @Barabas5532, I see that the assembly you provided was generated without optimizations.
Please try compiling it with the -O1/-O2 flags to enable optimizations. (https://godbolt.org/z/enzdaa6rf)
Barabas5532
commented
7 months ago Thanks for the hints on the optimisation flags. I see what went wrong now. When my component is being compiled, some compile flags that I though would be set up by esp-idf are missing.
I'm using a "Modern CMake" style for all of my components so that they can be cross platform to desktop for testing. This is documented in the manual.
It looks like the documentation is wrong though. In tools/cmake/component.cmake, a lot of magic happens to set up compile flags. This is all skipped for components defined using modern cmake.
Here are the compiler invocations for cJSON using the original 5.1.2 release, and then after modification as described in the docs. I've text replaced the actual path to esp-idf with $IDF_PATH so it's easier to read:
I have pushed the modified esp-idf here. Did I make a mistake setting up the pure cmake component? It is missing a lot of compile flags, including the optimisation level, and -fno-jump-tables, which is a workaround to some compiler bugs if I understand correctly: https://github.com/espressif/esp-idf/issues/1552#issuecomment-883600363.
Barabas5532
commented
7 months ago https://github.com/espressif/esp-idf/issues/10579 is related, but they never tried to work around the errors using add_subdirectory instead of putting the pure cmake files in the components folder. I guess I was not supposed to use the cmake API this way with esp-idf?
igrr
commented
7 months ago @Barabas5532 You can link pure CMake library targets to the application the way your example project does. However, since these targets are not added by the IDF build system, we don't add any compilation flags to such targets, except for the mandatory flags specified in the toolchain file.
If you describe the behavior you expect (both for a chip target and Linux target) I can try to recommend a way to achieve it.
Barabas5532
commented
7 months ago I'm designing most of my components to have no esp-idf dependencies by using abstraction layers on top of esp-idf. I can then build the components for desktop for testing using mock or fake implementation of the abstractions. The main feature of the project is audio processing for digital guitar effects, and I want to be able to extract the core features (audio processing, parameters and a web API to control the parameters) and run it in a digital audio workstation without any hardware. You can think of like an interactive integration test running on the host.
So the goal for the build system is to allow building these components into a firmware based on ESP-IDF, or for a unit test based on some test framework, or into a VST plugin based on JUCE. This should all be pretty straight forward using "Modern CMake".
For the desktop platform build, the components should look like modern cmake components, and there should be no references to esp-idf.
For the ESP32 build, I would like the components to have the same default compiler flags as components defined when using idf_component_register. I assume all of these are there for a reason. At the very least, the optimisation level should be propagated from menuconfig. Perhaps -fno-exceptions and -fno-rtti as well, I'm not so familiar with the rest. So maybe just having a way to tell esp-idf to define the compile flags globally would be enough? e.g. by setting CMAKE_LANG_FLAGS or putting the default flags in the toolchain file.
I'm already linking a common compiler flags component to all of my components like this, maybe I can add the missing flags there when ESP_PLATFORM is set? It is based on this idea from JUCE: https://github.com/juce-framework/JUCE/blob/d054f0d14dcac387aebda44ce5d792b5e7a625b3/extras/Build/CMake/JUCEHelperTargets.cmake#L24. This is not the nicest solution, it is easy to forget to link to this target and still end up with missing flags.
I see some others have gone for making two parallel build setups for conventional cmake and esp-idf. I also started out with something like this, but I would like to avoid duplicating the configuration:
if(ESP_PLATFORM)
idf_component_register(...)
else()
add_library(...)
endif()
Answers checklist.
General issue report
Compile a function doings some floating point math:
The generated code has inefficient stuff like loading from main memory on every iteration rather than keeping things in registers:
In an attempt to guide the compiler to a better solution, use the gcc register feature to place the temporaries in a specific floating point register:
Then the generated code is still not any faster in a benchmark, the loads are replaced by shuffling the value from f15 and f1, then doing the addition on f1, then moving the value back to f15. It is then immediately moved from f15 back to f0 for a comparison.
It would be great if the compiler could do a better job here, so that we don't have to write so much code in assembly for DSP functions.