-
Notifications
You must be signed in to change notification settings - Fork 22
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
Conversation
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.
Taking a look now! |
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.
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, |
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.
Out of curiosity does this additional pass add much overhead to the end-to-end codegen time?
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.
> 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.
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
intocheck_constraints
andcheck_early_constraints
), and also gives it a better error message.