Open antonysigma opened 10 months ago
Note to self: the Anderson2021-specific assertion failure producer_store_instances > 0
is eliminated when the returned Func
, captured via structured binding, is in-turn copied to the target Func
via the elementwise operation. Copy assignment operator doesn't work.
In other words, the following code triggers assertion failure:
std::tie(v_list[i], z_list[i], u_list[i])
= algorithm::linearized_admm::iterate(
v, z_prev, u_prev, K, omega_fn, psi_fns, lmb, mu, input);
This too:
const auto [_v_new, z_new, u_new]
= algorithm::linearized_admm::iterate(
v, z_prev, u_prev, K, omega_fn, psi_fns, lmb, mu, input);
v_list[i] = _v_new;
z_list[i] = z_new;
u_list[i] = u_new;
And this works:
const auto [_v_new, z_new, u_new]
= algorithm::linearized_admm::iterate(
v, z_prev, u_prev, K, omega_fn, psi_fns, lmb, mu, input);
using Halide::_;
v_list[i](x, y, c, _) = _v_new(x, y, c, _);
std::copy(u_new.begin(), u_new.end(), u_list[i].begin());
std::transform(z_new.begin(), z_new.end(), z_list[i].begin(), [](const auto& _z) -> Func{
Func _z_new;
_z_new(x, y, c, _) = _z(x, y, c, _);
return _z_new;
});
Hi @aekul,
Just curious, what does Condition failed: producer_store_instances > 0
do in the autoscheduler? I am using C++17's structured binding syntax to capture Functions as std::tuple
, but the Anderson2021
auto-scheduler doesn't seem to like it.
Comparing the code between Anderson2021
and Adams2019
, the key difference is in the condition producer_has_been_scheduled
. What does it do? And, how do I get started to debug my code?
producer_store_instances
should be the number of times the producer is allocated e.g. if the producer is stored at root, then it will be allocated once so producer_store_instances
will be 1. I would expect it to always be >= 1 (assuming that the value has actually been computed already) since there must be at least 1 allocation, so I think that's what the assert is checking.
I haven't had a chance to look too closely and don't recall all the details but producer_has_been_scheduled
is true for inputs and when site.produce != nullptr
(we know the loop nest where it will be produced). It sounds like the producer's featurization has not been computed for some reason.
For debugging, it would be useful to know whether producer_has_been_scheduled
is true and which stage the producer is. You could then try to see if that stage does in fact have its featurization computed or not. If you can reduce this to a more minimal example, I can potentially take a closer look too.
Thanks @aekul for the guidance. I will start by printing the current stage and the input stage names -- just to identify the halide Stage
causing the assertion failure. It should help me further reduce the repo code size for further debugging purposes.
Note to self: producer_has_been_scheduled
is false at the following expression. Consumer = u_new$1
, producer = _z
. site.produce
is nullptr. I will continue to debug...
Working draft for debugging purpose: https://github.com/antonysigma/proximal/tree/debug-producer-error
Observations: when we define the Halide
Func
and then return them asstd::tuple
, the generator can capture the algorithm pipeline and schedule it withMullapudi2016
autoscheduler. But notAnderson2021
. The autoscheduler reports:The same assertion failure happens with C++ structured bindings, as well as passing return values as function reference.
The offending line is shown below:
See also: #67 .