{"action":"created","issue":{"url":"https://api.github.com/repos/halide/Halide/issues/664","labels_url":"https://api.github.com/repos/halide/Halide/issues/664/labels{/name}","comments_url":"https://api.github.com/repos/halide/Halide/issues/664/comments","events_url":"https://api.github.com/repos/halide/Halide/issues/664/events","html_url":"https://github.com/halide/Halide/issues/664","id":57645110,"number":664,"title":"AOT-generated code should include Argument information","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":20,"created_at":"2015-02-13T19:48:15Z","updated_at":"2015-02-17T22:28:15Z","closed_at":null,"body":"It would be useful if AOT-generated Halide filters included a way to introspect the expected input and output arguments.\r\n\r\nStrawman proposal: Add simple array-of-struct data structures with names that match the filter. e.g.:\r\n\r\n    struct HalideArgumentDescriptor {\r\n      // Halide::Type isn't really available at runtime when running AOT;\r\n      // we'll just sorta replicate it here.\r\n      enum Type { kInt = 0, kUint = 1, kFloat = 2, kHandle = 3 };\r\n      const char* const name;\r\n      const bool is_buffer;\r\n      const Type type_code;\r\n      const uint8_t type_bits;\r\n      const uint8_t buffer_dimensions;\r\n      const double scalar_default;\r\n      const bool has_scalar_minmax;\r\n      const double scalar_min, scalar_max;\r\n    };\r\n    struct HalideArguments {\r\n      const int num_inputs;\r\n      const HalideArgumentDescriptor* inputs;\r\n      const int num_outputs;\r\n      const HalideArgumentDescriptor* outputs;\r\n    };\r\n\r\n    // If the filter we generate is like so:\r\n    // extern \"C\" int my_awesome_filter(buffer_t* in1, buffer_t* in2, int16_t i, float f, buffer_t* out);\r\n\r\n    // We'd generate something like:\r\n    extern \"C\" HalideArguments my_awesome_filter_halide_arguments = {\r\n      { \r\n        /* inputs */ \r\n        4, \r\n        {\r\n          { \"in1\", true, kUInt, 8, 3, 0.0, false, 0.0, 0.0 },\r\n          { \"in2\", true, kUInt, 8, 3, 0.0, false, 0.0, 0.0 },\r\n          { \"i\", false, kInt, 16, 0, 0.0, false, 0.0, 0.0 },\r\n          { \"f\", false, kFloat, 32, 0, 0.0, false, 0.0, 0.0 },\r\n        }\r\n        /* outputs */\r\n        1,\r\n        {\r\n          {\"out\", true, kUInt, 8, 3, 0.0, false, 0.0, 0.0 },\r\n        }\r\n        }\r\n      }\r\n    };\r\n\r\nSince we'd just be adding a new extern name that no one is likely to ever be looking for, existing code should be unaffected. It's a POD of modest size so addition to code size should be unimportant.\r\n\r\nSpecific layout and contents of the descriptor-struct open for discussion, of course. The one given above is similar to one I'm using in a private branch that suits my purposes.\r\n\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/halide/Halide/issues/comments/74768767","html_url":"https://github.com/halide/Halide/issues/664#issuecomment-74768767","issue_url":"https://api.github.com/repos/halide/Halide/issues/664","id":74768767,"user":{"login":"abadams","id":515398,"avatar_url":"https://avatars.githubusercontent.com/u/515398?v=3","gravatar_id":"","url":"https://api.github.com/users/abadams","html_url":"https://github.com/abadams","followers_url":"https://api.github.com/users/abadams/followers","following_url":"https://api.github.com/users/abadams/following{/other_user}","gists_url":"https://api.github.com/users/abadams/gists{/gist_id}","starred_url":"https://api.github.com/users/abadams/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/abadams/subscriptions","organizations_url":"https://api.github.com/users/abadams/orgs","repos_url":"https://api.github.com/users/abadams/repos","events_url":"https://api.github.com/users/abadams/events{/privacy}","received_events_url":"https://api.github.com/users/abadams/received_events","type":"User","site_admin":false},"created_at":"2015-02-17T22:28:15Z","updated_at":"2015-02-17T22:28:15Z","body":"That sounds fine to me. Default on, but move the choice outside of the\nbuild setup entirely. Though Zalman points out offline that you're going to\nhave to at least list the symbol in an exports file somewhere if your\ndefault symbol visibility is not public.\n\nOn Tue, Feb 17, 2015 at 2:02 PM, Dillon Sharlet <notifications@github.com>\nwrote:\n\n> How about just making the metadata default to on, and having a target flag\n> to turn it off? i.e. a flag NoMetadata, alongside NoAsserts, NoBoundsQuery,\n> ...\n>\n> —\n> Reply to this email directly or view it on GitHub\n> <https://github.com/halide/Halide/issues/664#issuecomment-74764005>.\n>\n"}}