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

Implement concept of unstable ABI into crossgen2 #40820

Merged
merged 2 commits into from
Aug 17, 2020

Conversation

davidwrighton
Copy link
Member

  • Use for the Vector types based on current defined stability rules
  • Will prevent compilation of methods with not yet stable abis, or calls to methods with said unstable apis

Fixes #13522

- Use for the Vector types based on current defined stability rules
- Will prevent compilation of methods with not yet stable abis, or calls to methods with said unstable apis
@MichalStrehovsky
Copy link
Member

We're already doing something similar for Vector<T>: we basically just say that the layout in Indeterminate and there's code checking for that that aborts crossgening the method whenever a piece of layout info is needed and it ends up Indeterminate.

Do we need to introduce a new general purpose mechanism here? Could we just have a FieldLayoutAlgorithm that returns Indeterminate layout for these same as for Vector<T> but only do it if the version bubble doesn't include CoreLib?

Cc @dotnet/crossgen-contrib

Copy link
Member

@janvorli janvorli left a comment

Choose a reason for hiding this comment

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

It looks ok, but I wonder about the same thing that @MichalStrehovsky said. It seems it would make the change more local.

@davidwrighton
Copy link
Member Author

Unfortunately, making the types have indeterminate size also prevents usage of the Vector intrinsics. This approach allows the intrinsics to continue to work and use the Vector128/256 types while simultaneously not permitting these apis to cross an ABI boundary.

@janvorli
Copy link
Member

Makes sense.

@janvorli janvorli merged commit b41f1c5 into dotnet:master Aug 17, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 7, 2020
@davidwrighton davidwrighton deleted the fix_vector_not_spc_aware branch April 20, 2021 17:44
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[crossgen2] Making sure Vector64/128/256 are not generated unless CoreLib is part of the version bubble
4 participants