-
Notifications
You must be signed in to change notification settings - Fork 130
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
Enable user-defined map parameter types #1640
base: main
Are you sure you want to change the base?
Conversation
…use auto in the for loop generated from the map
dace/codegen/targets/cpu.py
Outdated
if var in map_param_types.keys(): | ||
var_type = map_param_types[var] | ||
else: | ||
var_type = dtypes.result_type_of(infer_expr_type(r[0], sdfg.symbols), infer_expr_type(r[1], sdfg.symbols)) |
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.
I think it's better to use symbols_defined_at
dace/sdfg/nodes.py
Outdated
@@ -793,7 +793,10 @@ def new_symbols(self, sdfg, state, symbols) -> Dict[str, dtypes.typeclass]: | |||
result = {} | |||
# Add map params | |||
for p, rng in zip(self._map.params, self._map.range): | |||
result[p] = dtypes.result_type_of(infer_expr_type(rng[0], symbols), infer_expr_type(rng[1], symbols)) | |||
if p in self.map.param_types.keys(): | |||
result[p] = dtypes.typeclass(self.map.param_types[p]) |
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 isn't the value type typeclass?
dace/sdfg/nodes.py
Outdated
@@ -877,6 +880,7 @@ class Map(object): | |||
# List of (editable) properties | |||
label = Property(dtype=str, desc="Label of the map") | |||
params = ListProperty(element_type=str, desc="Mapped parameters") | |||
param_types = DictProperty(key_type=str, value_type=str, desc="Types of mapped parameters") |
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.
shouldn't param types have a typeclass value?
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.
I had saved the typestrings set by the transformation as a Dict(str,str), such that if a user wants to give the type info as a part of a transformation then the user can just write the str, but in a sense, having the type be a typeclass has information value in the "param_types" parameter, I will update.
dace/sdfg/nodes.py
Outdated
gpu_force_syncthreads = Property(dtype=bool, desc="Force a call to the __syncthreads for the map", default=False) | ||
|
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.
Unrelated
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.
Must have sneaked in from the other PR, will delete it
Co-authored-by: Tal Ben-Nun <[email protected]>
Co-authored-by: Tal Ben-Nun <[email protected]>
I also need to check why the param type can be none sometimes (some tests failing) |
There is one issue that I am currently trying to solve. (I need to find a way for the method "new_symbols" of an interstate edge not to infer the type of the parameters if the parameter was introduced by a map parameter set by the user) |
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.
Good addition, thank you! Two things are missing:
- My comment on symbols_defined_at (which should be computed as seldomly as possible)
- Missing unit test with types (maybe even an additional test that would fail with
auto
, as you now changed the behavior of codegen even in the default case)
Also, you do not have to keep merging with master, the merge queue will do that for you. Every merge puts an unnecessary burden on the CI queue.
dace/codegen/targets/cpu.py
Outdated
var_type = dtypes.result_type_of(infer_expr_type(r[0], state_dfg.symbols_defined_at(node)), | ||
infer_expr_type(r[1], state_dfg.symbols_defined_at(node))) |
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.
Please compute this once, preferably outside the loop of node.map.range. symbols_defined_at
can be an expensive function. Thanks!
@@ -1601,6 +1601,7 @@ def add_nested_sdfg( | |||
schedule=dtypes.ScheduleType.Default, | |||
location=None, | |||
debuginfo=None, | |||
symbol_type_mapping: Dict[str, dtypes.typeclass] = None |
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.
symbol_type_mapping: Dict[str, dtypes.typeclass] = None | |
symbol_type_mapping: Dict[str, dtypes.typeclass] = None, |
I will update the changes according to your comments. Thanks for pointing out the merge queue. Since auto was only used in a loop, the type of the loop variable depends on the type used in the loop condition. The auto case will never produce code that does not compile unless we compile with I have looked at the tests. No hard-coded SDFGs are used in the tests. I should create any SDFG I use through the API or a front-end, right? |
@ThrudPrimrose First of all, many tests use the SDFG API (e.g., add_edge_pair_test.py, you should use that. Second, for a wrong test case, a simple for loop with a mismatch in start/end types will run forever if not written correctly. See the following example (which one can write in dace): https://godbolt.org/z/YW5xsP51x |
Since there is no auto type, it is hard to create one that fails due to auto. I can easily create a test that mimics this behaviour by forcing the type of the variable. Then I can run it with subprocess and check for segfaults, should I do that or these tests should be enough? |
What I meant was to have a test that would fail if we generated |
Adding
param_types
variable I can set the loop params to what I want.I also remove the "auto" type to prefer the inferred type.
Using the inferred type instead of auto fixes the discrepancy of C++/CUDA inferred auto type and the inferred type between DaCe, where the discrepancy causes unnecessary implicit type conversion, resulting with a loss of performance.