Skip to content

Refactored memset and memcpy calls to D slices in multiple files #21147

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

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

AbhayPratap05
Copy link
Contributor

This PR replaces C-style memcpy and memset calls with D slice operations in several files:

  • compiler/src/dmd/common/outbuffer.d
  • compiler/src/dmd/dcast.d
  • compiler/src/dmd/root/array.d
  • compiler/src/dmd/root/bitarray.d

Changes made:

  1. Replaced memset calls with D slice assignments:
    (cast(ubyte*)ptr)[0 .. size] = 0
  2. Replaced memcpy calls with D slice copying:
    (cast(ubyte*)dest)[0 .. size] = (cast(const(ubyte)*)src)[0 .. size]

Testing:

  • Successfully built the compiler using Docker
  • Ran tests in the Docker container

Replace C-style memory functions with D slice operations in:\n- compiler/src/dmd/common/outbuffer.d\n- compiler/src/dmd/dcast.d\n- compiler/src/dmd/root/array.d\n- compiler/src/dmd/root/bitarray.d\n\nThis makes the code more idiomatic to D and safer.
@dlang-bot
Copy link
Contributor

Thanks for your pull request and interest in making D better, @AbhayPratap05! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

  • My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
  • My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
  • I have provided a detailed rationale explaining my changes
  • New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.


If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#21147"

Copy link
Member

@ibuclaw ibuclaw left a comment

Choose a reason for hiding this comment

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

Hi, thanks for the PR.

What is the net benefit of this change?

From a code-gen stance, both current and proposed changes are identical.

The current code is arguably more readable too. Drop the casts, and it would start to look like an improvement.

Copy link
Contributor

@dkorpel dkorpel 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 the changes to dcast.d.

OutBuffer and Array are very common optimized abstractions based on low-level building blocks. As a consequence, many of the translated slice expressions are more complex than the original memset/memcpy. On top of that, since slices have bounds checking, there is a performance regression risk (since we don't have the tester from the GSoC project yet), so please refrain from those refactorings for now.

@AbhayPratap05 AbhayPratap05 requested a review from dkorpel April 4, 2025 21:41
@AbhayPratap05
Copy link
Contributor Author

AbhayPratap05 commented Apr 4, 2025

This PR reverts the previous slice-based casts and instead:

  • Reverts all memset/memcpy replacements in outbuffer.d, array.d and bitarray.d
  • Updates dcast.d to use casting at allocation site instead of casting in slice operations

The changes follows mentor feedback to avoid performance regressions in OutBuffer and Array.

@AbhayPratap05 AbhayPratap05 requested a review from ibuclaw April 4, 2025 21:47
@dkorpel dkorpel added the Severity:Refactoring No semantic changes to code label Apr 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Severity:Refactoring No semantic changes to code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants