Skip to content
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

fix(Inference): Don't add constraints between static edges #693

Closed
wants to merge 1 commit into from

Conversation

croyzor
Copy link
Contributor

@croyzor croyzor commented Nov 15, 2023

As mentioned in #688, (here) don't require that both sides of a static edge have the same extension requirements, since the static edge often has the empty set.

@croyzor croyzor requested a review from acl-cqc November 15, 2023 09:38
Copy link

codecov bot commented Nov 15, 2023

Codecov Report

Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (d20bc74) 83.93% compared to head (676f4ea) 83.94%.

Files Patch % Lines
src/hugr/rewrite/replace.rs 0.00% 0 Missing and 1 partial ⚠️
Additional details and impacted files
@@           Coverage Diff           @@
##             main     #693   +/-   ##
=======================================
  Coverage   83.93%   83.94%           
=======================================
  Files          66       66           
  Lines       12706    12706           
  Branches    12706    12706           
=======================================
+ Hits        10665    10666    +1     
+ Misses       1285     1284    -1     
  Partials      756      756           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@@ -482,7 +482,7 @@ mod test {
FunctionType::new_linear(just_list.clone()).with_extension_delta(&exset),
)?;

let pred_const = cfg.add_constant(ops::Const::unary_unit_sum(), None)?;
let pred_const = cfg.add_constant(ops::Const::unary_unit_sum(), exset)?;
Copy link
Contributor

@acl-cqc acl-cqc Nov 15, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is because we can no longer infer an extension set for the Const itself, right? Presumably we could still use None for the LoadConstant? So what about changing the builder to automatically use pure for the Const node, but still allow specifying something (or None) for the LoadConstant?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, no, hang on - this is just the Const, there is no LoadConstant here. So IOW, the exset could be anything, that will play no further part in inference?

Hmmm, we should drop the param. That could be another PR/issue, tho.

Copy link
Contributor Author

@croyzor croyzor Nov 15, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should drop the parameter, default to pure for const and move this param to load_constant. I'll open another PR for this.
At the moment though, load_constant uses the extension set that is provided with the ConstId, which is why exset here needs to be specified when the const node is created

Copy link
Contributor

@acl-cqc acl-cqc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems sane, thanks - if tests are passing then looks good to me :-)

@acl-cqc
Copy link
Contributor

acl-cqc commented Nov 15, 2023

There is also the question of, if there's a constant value from a particular extension, do we want that to be reflected in the extension-delta of the containing Dfg/Function. This PR means it won't be. That might be fine (if values are passed around as generic YAML, say) or not fine (if we need to understand the extension to load CustomConst implementations)... this is probably worth making an issue?

@croyzor
Copy link
Contributor Author

croyzor commented Nov 15, 2023

There is also the question of, if there's a constant value from a particular extension, do we want that to be reflected in the extension-delta of the containing Dfg/Function. This PR means it won't be. That might be fine (if values are passed around as generic YAML, say) or not fine (if we need to understand the extension to load CustomConst implementations)... this is probably worth making an issue?

That's a good point. I believe the original behaviour is motivated by the latter (black box constants), which is a fair concern. Hence, we should scrap this PR!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants