-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add_requirement() maintenance #7045
Conversation
This PR started out as a quick fix to add Python bindings for the `add_requirements` methods on Pipeline and Generator (which were missing), but expanded a bit to fix other issues as well: - The implementation of `Generator::add_requirement` was subtly wrong, in that it only worked if you called the method after everything else in your `generate()` method. Now we accumulate requirements and insert them at the end, so you can call the method anywhere. - We had C++ methods that took both an explicit `vector<Expr>` and also a variadic-template version, but the former required a mutable vector... and fixing this to not require that ended up creating ambiguity about which overloaded call to use. Added an ugly enable_if thing to resolve this. (Side note #1: overloading methods to have both templated and non-templated versions with the same name is probably something to avoid in the future.) (Side note #2: we should probably thing more carefully about using variadic templates in our public API in the future; we currently use it pretty heavily, but it tends to be messy and hard to reason about IMHO.)
src/Generator.h
Outdated
@@ -3634,7 +3639,13 @@ class GeneratorBase : public NamesInterface, public AbstractGenerator { | |||
std::unique_ptr<GeneratorParamInfo> param_info_ptr; | |||
|
|||
std::string generator_registered_name, generator_stub_name; | |||
Pipeline pipeline; | |||
Pipeline pipeline_; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why the new underscores? I thought we typically didn't do that for member variables.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, was trying to track down usage by doing the 'rename and see what fails to compile' trick. Will revert.
Failures are unrelated |
* add_requirement() maintenance This PR started out as a quick fix to add Python bindings for the `add_requirements` methods on Pipeline and Generator (which were missing), but expanded a bit to fix other issues as well: - The implementation of `Generator::add_requirement` was subtly wrong, in that it only worked if you called the method after everything else in your `generate()` method. Now we accumulate requirements and insert them at the end, so you can call the method anywhere. - We had C++ methods that took both an explicit `vector<Expr>` and also a variadic-template version, but the former required a mutable vector... and fixing this to not require that ended up creating ambiguity about which overloaded call to use. Added an ugly enable_if thing to resolve this. (Side note halide#1: overloading methods to have both templated and non-templated versions with the same name is probably something to avoid in the future.) (Side note halide#2: we should probably thing more carefully about using variadic templates in our public API in the future; we currently use it pretty heavily, but it tends to be messy and hard to reason about IMHO.) * tidy * remove underscores
This PR started out as a quick fix to add Python bindings for the
add_requirements
methods on Pipeline and Generator (which were missing), but expanded a bit to fix other issues as well:Generator::add_requirement
was subtly wrong, in that it only worked if you called the method after everything else in yourgenerate()
method. Now we accumulate requirements and insert them at the end, so you can call the method anywhere.vector<Expr>
and also a variadic-template version, but the former required a mutable vector... and fixing this to not require that ended up creating ambiguity about which overloaded call to use. Added an ugly enable_if thing to resolve this.While working on this, also identified Issue #7044, which I haven't yet attempted to address.
(Side note #1: overloading methods to have both templated and non-templated versions with the same name is probably something to avoid in the future.)
(Side note #2: we should probably thing more carefully about using variadic templates in our public API in the future; we currently use it pretty heavily, but it tends to be messy and hard to reason about IMHO.)