Skip to content

Zero alloc: fix bug interaction between "opt" and top-level "all" #2424

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

Merged
merged 8 commits into from
Apr 10, 2024

Conversation

gretay-js
Copy link
Contributor

@gretay-js gretay-js commented Apr 9, 2024

The following example fails the check:

[@@@zero_alloc all]
let[@zero_alloc opt] foo x = (x,x)

but it is expected to pass the check by default (and fail with -check-zero-alloc all compiler flag).

This PR fixes the bug and adds a test to show the expected behavior.

The bug is that Clflags.zero_alloc_check_assert_all is checked too late. The cause of the bug is that "opt" annotations are removed by the middle-end (from_lambda transformation) if Lambda.is_check_enabled ~opt is false, but then in the backend, if Clflags.zero_alloc_check_assert_all is true, we add "assert zero_alloc" annotations on the same function, because it doesn't have "ignore" or "assume". The fix is to check the two flags in one place in the middle-end during from_lambda conversion. The reason that we don't check it all in the backend is the interaction with the dead code elimination in flambda: it's better to remove unnecessary "asserts" earlier. We can probably move this check even earlier after #2400 is merged, but that would be a separate PR for refactoring only.

As a result of the fix, we can eliminate the now-unused Ignore_all constructor from the middle-end and Cmm.

On top of #2416. Best review commit-by-commit.

@gretay-js gretay-js added bug Something isn't working backend labels Apr 9, 2024
cleanup after removal of closure and flambda2
- Use it in middle-end instead of backend: all decision about dropping
  Zero_alloc_attribute are in one place now.
- Add [Location.t] argument to [Zero_alloc_attribute.from_lambda]
  that comes from the location of the function definition. It
  corresponds to the previous use of [fun_dbg] in the backend.
  This location is only used for reporting friendlier errors to the user when
  the check enabled by [@@@zero_alloc all] fails on the function.
- Update call sites of [from_lambda] in the middle-end.
@gretay-js gretay-js force-pushed the zero_alloc_all_opt2 branch from 9b57582 to 9877b46 Compare April 9, 2024 15:18
@gretay-js gretay-js requested a review from xclerc April 10, 2024 11:02
@gretay-js gretay-js marked this pull request as ready for review April 10, 2024 11:02
Copy link
Contributor

@xclerc xclerc left a comment

Choose a reason for hiding this comment

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

I have arguably not really paid
attention to the semantics of
[@@@zero_alloc all], but I find
it a bit confusing. It looks like
it applies to the whole file, while
I would expect it to apply "from
that point". Is that correct?

@gretay-js
Copy link
Contributor Author

It looks like
it applies to the whole file, while
I would expect it to apply "from
that point". Is that correct?

yes, [@@@zero_alloc all] currently applies to the whole file. it's not ideal, but it was easier (because the flag is only used in the backend). one way to improve it would be to keep track of the scope of this attribute similarly to the way we keep track of the warnings scopes.

@xclerc
Copy link
Contributor

xclerc commented Apr 10, 2024

Indeed, my expectations came from the
way warnings work.

Copy link
Contributor

@xclerc xclerc left a comment

Choose a reason for hiding this comment

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

I think the pull request has a positive
effect, but as noted above the
semantics is confusing/unexpected
and should probably be tweaked in
a future pull request.

@gretay-js gretay-js merged commit a14431d into ocaml-flambda:main Apr 10, 2024
17 checks passed
gretay-js added a commit to gretay-js/flambda-backend that referenced this pull request Apr 11, 2024
…aml-flambda#2424)

* Remove unused function from Cmm_helpers

cleanup after removal of closure and flambda2

* Use [Clflags.zero_alloc_check_assert_all] earlier

- Use it in middle-end instead of backend: all decision about dropping
  Zero_alloc_attribute are in one place now.
- Add [Location.t] argument to [Zero_alloc_attribute.from_lambda]
  that comes from the location of the function definition. It
  corresponds to the previous use of [fun_dbg] in the backend.
  This location is only used for reporting friendlier errors to the user when
  the check enabled by [@@@zero_alloc all] fails on the function.
- Update call sites of [from_lambda] in the middle-end.

* Remove [Ignore_assert_all] from middle-end

* Remove [Ignore_assert_all] from the backend

* Add a new test

* Fix corner case of [@@@zero_alloc all] for "opt" flag

* Update test output and remove CR-soon.

* Format
Forestryks pushed a commit to Forestryks/flambda-backend that referenced this pull request Apr 17, 2024
…aml-flambda#2424)

* Remove unused function from Cmm_helpers

cleanup after removal of closure and flambda2

* Use [Clflags.zero_alloc_check_assert_all] earlier

- Use it in middle-end instead of backend: all decision about dropping
  Zero_alloc_attribute are in one place now.
- Add [Location.t] argument to [Zero_alloc_attribute.from_lambda]
  that comes from the location of the function definition. It
  corresponds to the previous use of [fun_dbg] in the backend.
  This location is only used for reporting friendlier errors to the user when
  the check enabled by [@@@zero_alloc all] fails on the function.
- Update call sites of [from_lambda] in the middle-end.

* Remove [Ignore_assert_all] from middle-end

* Remove [Ignore_assert_all] from the backend

* Add a new test

* Fix corner case of [@@@zero_alloc all] for "opt" flag

* Update test output and remove CR-soon.

* Format
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backend bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants