Skip to content
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

Inline functions in a referenced project optimized incorrectly #17903

Open
rca22 opened this issue Oct 21, 2024 · 5 comments
Open

Inline functions in a referenced project optimized incorrectly #17903

rca22 opened this issue Oct 21, 2024 · 5 comments
Labels
Milestone

Comments

@rca22
Copy link

rca22 commented Oct 21, 2024

In the attached example, we create three types;

  • ID, in ClassLibrary1
  • ID2, in ClassLibrary1, which relies on ID
  • ID3 in ConsoleApp1, which relies on ID2.

In each of these we override equality and comparison operators, using inline functions to improve performance for ID3. (Note that this repro is a minimal example from more complicated code where this makes more sense!)

We create instances of each in the console app. and check that two unequal values of each type are reported as unequal by the compiler.
In Release mode only, the third assertion, that two obviously different instances of ID3 are unequal fails.

To repro, please run the attached program.
repro.zip

Expected behavior

I expect the program to exit with code 0.

Actual behavior

An exception is thrown in the last equality check, for aBarBar versus bBarBar

Known workarounds

Running this in debug mode fixes the issue.
Putting the definitions of ID and ID2 in the same project as ID3 fixes the issue. Because of this, I suspect this issue is something to do with incorrect optimisations around inlining functions from other projects.
Changing ID from a struct into a class by removing all the attributes associated with it fixes the issue.

Related information

Tested in .NET 8, SDKs 8.0.100 and 8.0.403
Windows 10.
VS 2022 for editing.

@github-actions github-actions bot added this to the Backlog milestone Oct 21, 2024
@vzarytovskii
Copy link
Member

vzarytovskii commented Oct 21, 2024

An exception is thrown in the last equality check, for aBarBar versus bBarBar

What's the exception? What's yielded in the nightly 9.0 sdk? Does it change with realsig off? It could also be related to the additional equality generated.

@rca22
Copy link
Author

rca22 commented Oct 21, 2024

An exception is thrown in the last equality check, for aBarBar versus bBarBar

What's the exception? What's yielded in the nightly 9.0 sdk? Does it change with realsig off? It could also be related to the additional equality generated.

To be clear the last equality check reads if aBarBar = bBarBar then failwith "Expect aBarBar and bBarBar to differ"; earlier aBarBar and bBarBar are set up to be clearly different. The exception is not an internal one; just there to indicate the deviation from expected behaviour.

@vzarytovskii
Copy link
Member

An exception is thrown in the last equality check, for aBarBar versus bBarBar

What's the exception? What's yielded in the nightly 9.0 sdk? Does it change with realsig off? It could also be related to the additional equality generated.

To be clear the last equality check reads if aBarBar = bBarBar then failwith "Expect aBarBar and bBarBar to differ"; earlier aBarBar and bBarBar are set up to be clearly different. The exception is not an internal one; just there to indicate the deviation from expected behaviour.

I see, thanks. It appears that it's failing in SDK 6.0, could've been there forever.

@T-Gro
Copy link
Member

T-Gro commented Oct 21, 2024

This is what the decompiled Release code looks like for the Equals check of ID3.
As you can see, the name ID4 was being reused for both sides, ending up comparing a string with the same string, all the time.

Image

@vzarytovskii
Copy link
Member

This is what the decompiled Release code looks like for the Equals check of ID3.
As you can see, the name ID4 was being reused for both sides, ending up comparing a string with the same string, all the time.

Image

That's some awkward codegen. We will need to see whether it's a recent regression. If it is, we need to fix it for 9.0.200

@T-Gro T-Gro modified the milestones: Backlog, November-2024 Oct 29, 2024
@T-Gro T-Gro added Area-Compiler-Optimization The F# optimizer, release code gen etc. help wanted labels Nov 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: New
Development

No branches or pull requests

3 participants