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

Add error message for obscure case with parameters. #214

Merged
merged 2 commits into from
Dec 18, 2024

Conversation

reventlov
Copy link
Collaborator

Prior to this change, if a user omitted the length of an integer parameter and used that parameter as an argument to an operator or function, the compiler with throw an AttributeError instead of providing a useful message.

This is because the check that integer runtime parameters have an explicit size happened later than the function in expression_bounds.py that tried to use the size.

This change moves the check earlier (incidentally spliting check_constraints into check_constraints and
check_early_constraints), and also gives it a better error message.

Prior to this change, if a user omitted the length of an integer
parameter *and* used that parameter as an argument to an operator or
function, the compiler with throw an `AttributeError` instead of
providing a useful message.

This is because the check that integer runtime parameters have an
explicit size happened later than the function in `expression_bounds.py`
that tried to use the size.

This change moves the check earlier (incidentally spliting
`check_constraints` into `check_constraints` and
`check_early_constraints`), and also gives it a better error message.
@reventlov reventlov requested a review from EricRahm December 13, 2024 01:10
@EricRahm
Copy link
Collaborator

Taking a look now!

Copy link
Collaborator

@EricRahm EricRahm left a comment

Choose a reason for hiding this comment

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

Thanks for adding this check, lgtm. Just a very minor concern about whether or not an additional pass will add more overhead (my guess is it's negligible).

@@ -319,6 +319,7 @@ def process_ir(ir, stop_before_step):
symbol_resolver.resolve_field_references,
type_check.annotate_types,
type_check.check_types,
constraints.check_early_constraints,
Copy link
Collaborator

Choose a reason for hiding this comment

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

Out of curiosity does this additional pass add much overhead to the end-to-end codegen time?

Copy link
Collaborator Author

@reventlov reventlov Dec 18, 2024

Choose a reason for hiding this comment

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

> python3 -m cProfile ./embossc --output-path ~/scratch ~/scratch/large.emb

         25766374 function calls (23764959 primitive calls) in 17.613 seconds

   Ordered by: cumulative time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
    181/1    0.014    0.000   18.280   18.280 {built-in method builtins.exec}
[...]
        1    0.000    0.000    0.003    0.003 constraints.py:717(check_early_constraints)
[...]
        8    0.000    0.000    0.002    0.000 constraints.py:365(_check_type_requirements_for_parameter_type)
[...]

Looks like <0.02% of the overall compilation time. large.emb does have a few parameters, but is not parameter-heavy; I imagine that an .emb with a lot of parameters would pay a correspondingly higher compile time cost.

@reventlov reventlov merged commit 75bdc4c into google:master Dec 18, 2024
6 checks passed
@reventlov reventlov deleted the parameter_no_size_bug branch December 18, 2024 21:51
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