{"action":"opened","issue":{"url":"https://api.github.com/repos/halide/Halide/issues/1007","labels_url":"https://api.github.com/repos/halide/Halide/issues/1007/labels{/name}","comments_url":"https://api.github.com/repos/halide/Halide/issues/1007/comments","events_url":"https://api.github.com/repos/halide/Halide/issues/1007/events","html_url":"https://github.com/halide/Halide/issues/1007","id":126769386,"number":1007,"title":"Recursive bounds inference can produce incorrect results in define_extern usage","user":{"login":"steven-johnson","id":328955,"avatar_url":"https://avatars.githubusercontent.com/u/328955?v=3","gravatar_id":"","url":"https://api.github.com/users/steven-johnson","html_url":"https://github.com/steven-johnson","followers_url":"https://api.github.com/users/steven-johnson/followers","following_url":"https://api.github.com/users/steven-johnson/following{/other_user}","gists_url":"https://api.github.com/users/steven-johnson/gists{/gist_id}","starred_url":"https://api.github.com/users/steven-johnson/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/steven-johnson/subscriptions","organizations_url":"https://api.github.com/users/steven-johnson/orgs","repos_url":"https://api.github.com/users/steven-johnson/repos","events_url":"https://api.github.com/users/steven-johnson/events{/privacy}","received_events_url":"https://api.github.com/users/steven-johnson/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2016-01-14T23:08:27Z","updated_at":"2016-01-14T23:08:27Z","closed_at":null,"body":"This is complicated to explain, so bear with me.\r\n\r\nIt's legal in Halide to have recursive bounds expressions for inputs to a Func; this can happen either explicitly, e.g.:\r\n\r\n      in.set_extent(0, ((in.extent(0)+1)/2)*2)\r\n\r\nor implicitly (e.g., as a result of using BoundaryConditions in the function definitions.\r\n\r\nUnfortunately, when used in a multi-stage pipeline of realized functions (connected via define_extern), recursive bounds query expressions aren't always evaluated properly; in some cases, this can lead to pathological memory usage; in others, it can produce incorrect output.\r\n\r\nI've attached an example of incorrect-output produced by this approach; in a nutshell, we have a toplevel pipeline that calls two define_extern()'ed functions; the \"middle\" function uses a BoundaryCondition that produces a recursive boundary condition for its input; when called in this pipeline, it ends up producing an \"input required\" that is always 1x1 pixel, regardless of the actual input size. (This basically means that all but that pixel in the output is essentially uninitialized). \r\n\r\nThis is a perplexing problem, as I don't know what the right answer is; in other fora, it's been suggested that the right way to handle bounds-query logic is to iterate until there's a stable answer, but this isn't what currently happens with define_extern() bounds queries, and even if it was, it's not clear whether it could be bounded effectively for all general cases.\r\n\r\n\r\n[bad_recursive_bounds_query.cpp.txt](https://github.com/halide/Halide/files/91131/bad_recursive_bounds_query.cpp.txt)\r\n"}}