Skip to content
This repository has been archived by the owner on Jan 23, 2023. It is now read-only.
/ corefx Public archive

[NO MERGE] BitOps analysis CoreFX (WIP) #34917

Closed
wants to merge 2 commits into from

Conversation

grant-d
Copy link

@grant-d grant-d commented Jan 29, 2019

Update call sites for dotnet/coreclr#22225

Note that this PR will not build right now - it is being used to analyze the consolidation of call sites for https://github.com/dotnet/corefx/issues/32269.

cc @tannergooding

@@ -45,12 +45,12 @@ internal static bool AreBytesEqual(byte[] src, byte[] tgt)

internal static void ClearBit(ref int value, uint bitmask)
{
value = (int)(((uint)value) & ((uint)(~bitmask)));
BitOps.ClearBit(ref value, (int)bitmask);
Copy link
Author

Choose a reason for hiding this comment

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

Motivation to use uint for declared offset param

Copy link
Author

Choose a reason for hiding this comment

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

I need to do some more analysis of the original code to make sure that the refactor is functionally equivalent.

}

internal static void SetBit(ref int value, uint bitmask)
{
value = (int)(((uint)value) | ((uint)bitmask));
BitOps.InsertBit(ref value, (uint)bitmask);
Copy link
Author

Choose a reason for hiding this comment

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

I need to do some more analysis of the original code to make sure that the refactor is functionally equivalent.

@stephentoub
Copy link
Member

Thanks. As the issue hasn't been reviewed/approved yet, I'm going to close this. Obviously you can continue to iterate on it and use it as reference until it's actionable as a PR.

@tannergooding
Copy link
Member

@stephentoub, at this point the BitOps class is internal and this is trying to centralize all the locations we are using bit operations throughout the framework/runtime code.

So, we should be able to take this regardless of the status of the corresponding API proposal (given that it is all internal). I imagine we will want to take this as well, given that it simplifies our existing code (by ensuring we have a single helper method, rather than 5, 10, or more duplicates).

@stephentoub
Copy link
Member

at this point the BitOps class is internal and this is trying to centralize all the locations we are using bit operations throughout the framework/runtime code.

Internal where? It's not in the PR. That's also not how the PR is described. And it wouldn't need to be a no-merge / wip if it were just about changing some call sites to use some internal helper... if/when that's what it is, it can be opened for that.

@tannergooding
Copy link
Member

Its internal in CoreCLR now (with one operation) and there is a corresponding change against CoreCLR doing what I described above (centralizing the rest of the bitops already used in CoreCLR).

I agree this PR could wait until the CoreCLR side is merged, however.

@karelz karelz added this to the 3.0 milestone Mar 18, 2019
@grant-d grant-d deleted the grant-d.bitsfx branch April 16, 2019 02:51
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants