-
Notifications
You must be signed in to change notification settings - Fork 783
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
Merge fields of the same type on multi-case union structs #11718
Conversation
This looks plausible. Can't we emit a union struct (a struct with overlapping fields)? We ideally want to keep the name |
The original surface area must be the same, so this property must appear:
even if its implementation goes to a shared field. Also, we will need to review and add reflection tests for struct unions of this kind. |
Got it.
I was surprised there were no IL tests for this that would've failed here.
Hm, yes, that would be ideal. However, I reckon messing around with explicit overlapping layout would be far trickier (fsharp/fslang-suggestions#699 (comment) and fsharp/fslang-suggestions#699 (comment)) than this seemingly straightforward approach. Unless you're opposed to it, I'd like to continue with what I'm doing. It could be a quick win and a (perhaps temporary) stepping stone towards a better solution. |
I'm not sure it would be that hard. The main thing is determining the exact restrictions on what works and what doesn't in CommonIL |
Certainly it's ok to continue to get this green. Then I'd encourage you to try a spike to do the explicit fields. |
Ok, I've decided to start over with explicit fields and in many ways it looks simpler than the original approach would be. I do have a couple of questions/problems though.
|
Overlapping refence type fields of different types also lead to some strange behavior. This snippet prints some undefined part of the process memory (or it throws |
Tangentially related issue and some background by @jkotas dotnet/roslyn#42617 (comment) |
I see, I hadn't realised debugging would break. I suppose One option would be to reduce the fields to Another option would be to only share fields for identical types (
Could you link to the source please? I'm not quite sure what you're referring to.
In the compiler you can't unfortunately, you'd need to write new logic that evaluates this in terms of the machine int size. |
So I was thinkin |
A quick and (very) dirty proof of concept of implementing fsharp/fslang-suggestions#699. The thread contains many other potential improvements, but I'm solely concentrating on the original, approved suggestion here. The optimization kicks in when each case of a struct DU comprises one field of the same type.Given
Old emitted struct
New emitted struct
Extra ctors can be removedEquals
,CompareTo
andGetHashCode
can be simplifiedCurrently retains the field name specified in the first DU case, not sure if OKExtend the optimization to work across multi-field cases by sharing the common fields but retaining the rest (Can this be done later, or is it better to do it now?)Nullary cases should not prevent the optimizationWill old compilers be able to consume these structs and emit correct field getters without extra work? If not, what needs to be done?So far it looks like it should be simple enough. Is there some glaring oversight on my part?