@dsharletg - likely related to halide/Halide#6020 ? (I'll explore by adding explicit tailstrategies to the code)
Source code worked as-is on Halide 12
Sure! I'd still like to understand why your build was failing, though :)
It could be a difference in how we're building LLVM or what targets are enabled?
These are our cmake flags:
51 CMAKE_HALIDE_OPTIONS:= \
52 -DLLVM_DIR=${LLVM_ROOT}/release/lib/cmake/llvm \
53 -DCLANG=${CLANG} \
54 -DWARNINGS_AS_ERRORS=OFF \
55 -DWITH_PYTHON_BINDINGS=OFF \
56 -DWITH_TEST_AUTO_SCHEDULE=ON \
57 -DWITH_TEST_CORRECTNESS=OFF \
58 -DWITH_TEST_ERROR=ON \
59 -DWITH_TEST_WARNING=ON \
60 -DWITH_TEST_PERFORMANCE=ON \
61 -DWITH_TEST_OPENGL=OFF \
62 -DWITH_TEST_GENERATOR=ON \
63 -DWITH_APPS=OFF \
64 -DWITH_TUTORIALS=OFF \
65 -DWITH_DOCS=OFF \
66 -DWITH_UTILS=OFF .
51 CMAKE_HALIDE_OPTIONS:= \
52 -DLLVM_DIR=${LLVM_ROOT}/release/lib/cmake/llvm \
53 -DCLANG=${CLANG} \
54 -DWARNINGS_AS_ERRORS=OFF \
55 -DWITH_PYTHON_BINDINGS=OFF \
56 -DWITH_TEST_AUTO_SCHEDULE=ON \
57 -DWITH_TEST_CORRECTNESS=OFF \
58 -DWITH_TEST_ERROR=ON \
59 -DWITH_TEST_WARNING=ON \
60 -DWITH_TEST_PERFORMANCE=ON \
61 -DWITH_TEST_OPENGL=OFF \
62 -DWITH_TEST_GENERATOR=ON \
63 -DWITH_APPS=OFF \
64 -DWITH_TUTORIALS=OFF \
65 -DWITH_DOCS=OFF \
66 -DWITH_UTILS=OFF .
oh, llvm - ok, likely that. Will double check, it might be that our in house llvm build has limited targets.
That would make sense. Our binaries contain all supported backends
Totally! Hopefully we'll be able to get the release latency (after LLVM) even tighter for the next releases :)
@alexreinking:matrix.org Hiya! I'm looking at backporting PR #6405 from master to create a v13.0.1 release. Should I create a "backports/13.x" branch and merge things in there, and then push the results into "releases/13.x"? Just trying to match what Andrew and I are seeing in the repo to follow conventions. Any suggestions?
I use
backports/N.x for staging changes to release/N.x. When it's ready, I open a PR with release/N.x as the target branch. There is CI set up for this scenario. Be sure to include a commit that bumps the version to 13.0.1.
release/N.x is (or ought to be) protected (like master), so you can't push to it
No. When creating a new major release, we fork it off of
master.
Also, I prefer to not squash commits from
backports/N.x into release/N.x. I think the cherry-picking history is valuable (as are any separate/additional patches necessary to correctly backport) as is keeping the version number bump separate.
No problem! Happy to share the release responsibility :)
Sweet! Happy to help! :)
I bring it up because the repository default PR-merge mode is to squash
I think it is... I would add it to the
share/doc/Halide folder (at least on Linux), along with the other READMEs.
Sure... I can review, but I'm traveling through 12/5, and pushing for the 11/19 PLDI deadline, so my bandwidth is limited
Can someone please explain this message
Loop over output.s0.x has extent output.extent.0. Can only vectorize loops over a constant extent > 1. Let's say we're dealing with floats and SSE, I don't get why the loop over x can't simply loop over 1/4 of the extent and process 4 float values at the time (let's ignore the case where extent is not divisible by 4). Do I need to split x into constant size chunks in order to get vectorization working?
5 replies
mac-buildbot-1 is going DOWN for a long-overdue OS upgrade (since I am actually physically in front of it). Back up soon-ish I hope.
To call some AOT generated code from a Hexagon binary (running on the simulation), what do I need to link my Hexagon binary to? I am getting some error messages about undefined symbols (halide_string_to_string, halide_msan_annotate_memory_is_initialized, a couple of others) but libHalide.so and libHalide.a are both x86_64 libs
(I am getting the error messages when I run the simulation)
Or is there perhaps a way to statically link those missing functions when I run the AOT generator?
It sounds like you're missing a runtime perhaps? What was the target for the AOT generated code?
I can see some DSP libs in Hexagon SDK's copy of Halide, but I don't seem to be generating these libs when I am building Halide from source
this might be relevant
$ objdump -t build/host/ResizeNearestNeighbor.a | grep halide_
00000000 l df *ABS* 00000000 halide_buffer_t.cpp
00000000 *UND* 00000000 halide_error
00000000 *UND* 00000000 halide_msan_annotate_memory_is_initialized
00000000 w F .text.halide_qurt_hvx_lock 000000b0 halide_qurt_hvx_lock
00000000 w F .text.halide_qurt_hvx_unlock 000000ac halide_qurt_hvx_unlock
00000000 w F .text.halide_qurt_hvx_unlock_as_destructor 00000008 halide_qurt_hvx_unl
ock_as_destructor
00000000 *UND* 00000000 halide_string_to_string
00000000 w F .text.halide_vtcm_free 00000008 halide_vtcm_free
00000000 w F .text.halide_vtcm_malloc 0000000c halide_vtcm_malloc
That ResizeNearestNeighbor.a is the AOT generation result. It already has references to these functions at this stage.
So either I need to link them statically at AOT-generation-time or I need to dynamically link some runtime lib... and hope that it will work on the hexagon simulator
Now I am just missing definitions for halide_error and halide_print
Problem solved