[APX] Follow up on #104637: rename extended registers and bug fixes.

[Ruihan-Yin]

resolving the comments from #104637.

renamed Egprx to Rx.

Fixed the copy logic for CONTEXT data structure, now it should be able to correctly handle the cases with Avx512 and APX.

[Ruihan-Yin]

Hi @BruceForstall, I made the changes to revert the raw byte code in contetx2.S. Looks like some builds are still failing: OSX/tvOS, linux with GCC and musl.

Are these in this location because it mimics the layout of XSAVE? Or is it arbitrary? Why are these named "Egpr16" instead of just "R16"?

Also regarding this question, I have renamed the registers, and the layout should be arbitrary, we use __cpuid(0D, featureIndex) to query the size and offset of the XSTATE feature, and then load/store them into a abstracted data structure context. Detail behavior is defined in CONTEXTToNativeContext in context.cpp. So I think we don't need to change the layout.

But I do have another open to discuss, I've logged the details in context.cpp. It would be much appreciated if you could share some thoughts.

[BruceForstall]

I presume we will never support APX on OSX/tvOS or any Apple product, since they are actively deprecating Intel processor support. So the build should work around that with FEATURE_APX ifdefs or similar. If GCC and musl don't support an updated assembler yet, then I guess the change to symbolic code can't be made.

But I do have another open to discuss, I've logged the details in context.cpp. It would be much appreciated if you could share some thoughts.

This is a question about CONTEXT handling in the PAL -- @janvorli or @jkotas might be better to answer.

[janvorli]

@Ruihan-Yin there is no need to copy the contents of the CONTEXT in one block. You can copy the APX part separately. It was just a convenience when there was one extra block, so we could do a single copy.

[Ruihan-Yin]

@Ruihan-Yin there is no need to copy the contents of the CONTEXT in one block. You can copy the APX part separately. It was just a convenience when there was one extra block, so we could do a single copy.

Thanks for the clarification, I will make the changes accordingly.

[Ruihan-Yin]

I presume we will never support APX on OSX/tvOS or any Apple product, since they are actively deprecating Intel processor support. So the build should work around that with FEATURE_APX ifdefs or similar. If GCC and musl don't support an updated assembler yet, then I guess the change to symbolic code can't be made.

But I do have another open to discuss, I've logged the details in context.cpp. It would be much appreciated if you could share some thoughts.

This is a question about CONTEXT handling in the PAL -- @janvorli or @jkotas might be better to answer.

Now that we still have dependency on GCC and musl, we can let the raw byte code stay for a little longer. But I can still cover the needed changes for renaming and context copy in this PR

[Copilot]

Pull Request Overview

This PR renames extended registers from Egprx to Rx and fixes the copy logic for the CONTEXT structure related to AVX512 and APX handling.

• Renamed register fields from Egpr16–Egpr31 to R16–R31 in the PAL header.
• Updated memcpy calls in context.cpp to use the new register naming.
• Adjusted the assignment operator to separate APX register copying while handling AVX512.

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/coreclr/pal/src/thread/context.cpp	Updated memcpy calls and assignment operator logic to reflect register renaming and fix copy issues.
src/coreclr/pal/inc/pal.h	Renamed structure members from Egpr16–Egpr31 to R16–R31.

Comments suppressed due to low confidence (1)

src/coreclr/pal/inc/pal.h:1523

• [nitpick] The register fields have been renamed to 'R16-R31'; please verify that all related code references are updated accordingly.

DWORD64 R16;

[Ruihan-Yin]

failures look irrelevant, rerunning CI
@dotnet/intel for review

[Ruihan-Yin]

Hi @BruceForstall, could you please give this another review? Thanks!

[tannergooding]

LGTM. @janvorli or @jkotas should also sign-off since this is a PAL side change

[janvorli]

LGTM, thank you!

[Ruihan-Yin]

resolving the comments from #104637.

renamed Egprx to Rx.

Fixed the copy logic for CONTEXT data structure, now it should be able to correctly handle the cases with Avx512 and APX.

[Ruihan-Yin]

Hi @BruceForstall, I made the changes to revert the raw byte code in contetx2.S. Looks like some builds are still failing: OSX/tvOS, linux with GCC and musl.

Are these in this location because it mimics the layout of XSAVE? Or is it arbitrary? Why are these named "Egpr16" instead of just "R16"?

Also regarding this question, I have renamed the registers, and the layout should be arbitrary, we use __cpuid(0D, featureIndex) to query the size and offset of the XSTATE feature, and then load/store them into a abstracted data structure context. Detail behavior is defined in CONTEXTToNativeContext in context.cpp. So I think we don't need to change the layout.

But I do have another open to discuss, I've logged the details in context.cpp. It would be much appreciated if you could share some thoughts.

[BruceForstall]

I presume we will never support APX on OSX/tvOS or any Apple product, since they are actively deprecating Intel processor support. So the build should work around that with FEATURE_APX ifdefs or similar. If GCC and musl don't support an updated assembler yet, then I guess the change to symbolic code can't be made.

But I do have another open to discuss, I've logged the details in context.cpp. It would be much appreciated if you could share some thoughts.

This is a question about CONTEXT handling in the PAL -- @janvorli or @jkotas might be better to answer.

[janvorli]

@Ruihan-Yin there is no need to copy the contents of the CONTEXT in one block. You can copy the APX part separately. It was just a convenience when there was one extra block, so we could do a single copy.

[Ruihan-Yin]

@Ruihan-Yin there is no need to copy the contents of the CONTEXT in one block. You can copy the APX part separately. It was just a convenience when there was one extra block, so we could do a single copy.

Thanks for the clarification, I will make the changes accordingly.

[Ruihan-Yin]

I presume we will never support APX on OSX/tvOS or any Apple product, since they are actively deprecating Intel processor support. So the build should work around that with FEATURE_APX ifdefs or similar. If GCC and musl don't support an updated assembler yet, then I guess the change to symbolic code can't be made.

But I do have another open to discuss, I've logged the details in context.cpp. It would be much appreciated if you could share some thoughts.

This is a question about CONTEXT handling in the PAL -- @janvorli or @jkotas might be better to answer.

Now that we still have dependency on GCC and musl, we can let the raw byte code stay for a little longer. But I can still cover the needed changes for renaming and context copy in this PR

[Copilot]

Pull Request Overview

This PR renames extended registers from Egprx to Rx and fixes the copy logic for the CONTEXT structure related to AVX512 and APX handling.

• Renamed register fields from Egpr16–Egpr31 to R16–R31 in the PAL header.
• Updated memcpy calls in context.cpp to use the new register naming.
• Adjusted the assignment operator to separate APX register copying while handling AVX512.

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/coreclr/pal/src/thread/context.cpp	Updated memcpy calls and assignment operator logic to reflect register renaming and fix copy issues.
src/coreclr/pal/inc/pal.h	Renamed structure members from Egpr16–Egpr31 to R16–R31.

Comments suppressed due to low confidence (1)

src/coreclr/pal/inc/pal.h:1523

• [nitpick] The register fields have been renamed to 'R16-R31'; please verify that all related code references are updated accordingly.

DWORD64 R16;

[Ruihan-Yin]

failures look irrelevant, rerunning CI
@dotnet/intel for review

[Ruihan-Yin]

Hi @BruceForstall, could you please give this another review? Thanks!

[tannergooding]

LGTM. @janvorli or @jkotas should also sign-off since this is a PAL side change

[janvorli]

LGTM, thank you!

[Ruihan-Yin]

resolving the comments from #104637.

renamed Egprx to Rx.

Fixed the copy logic for CONTEXT data structure, now it should be able to correctly handle the cases with Avx512 and APX.

[Ruihan-Yin]

Hi @BruceForstall, I made the changes to revert the raw byte code in contetx2.S. Looks like some builds are still failing: OSX/tvOS, linux with GCC and musl.

Are these in this location because it mimics the layout of XSAVE? Or is it arbitrary? Why are these named "Egpr16" instead of just "R16"?

Also regarding this question, I have renamed the registers, and the layout should be arbitrary, we use __cpuid(0D, featureIndex) to query the size and offset of the XSTATE feature, and then load/store them into a abstracted data structure context. Detail behavior is defined in CONTEXTToNativeContext in context.cpp. So I think we don't need to change the layout.

But I do have another open to discuss, I've logged the details in context.cpp. It would be much appreciated if you could share some thoughts.

[BruceForstall]

I presume we will never support APX on OSX/tvOS or any Apple product, since they are actively deprecating Intel processor support. So the build should work around that with FEATURE_APX ifdefs or similar. If GCC and musl don't support an updated assembler yet, then I guess the change to symbolic code can't be made.

But I do have another open to discuss, I've logged the details in context.cpp. It would be much appreciated if you could share some thoughts.

This is a question about CONTEXT handling in the PAL -- @janvorli or @jkotas might be better to answer.

[janvorli]

@Ruihan-Yin there is no need to copy the contents of the CONTEXT in one block. You can copy the APX part separately. It was just a convenience when there was one extra block, so we could do a single copy.

[Ruihan-Yin]

@Ruihan-Yin there is no need to copy the contents of the CONTEXT in one block. You can copy the APX part separately. It was just a convenience when there was one extra block, so we could do a single copy.

Thanks for the clarification, I will make the changes accordingly.

[Ruihan-Yin]

I presume we will never support APX on OSX/tvOS or any Apple product, since they are actively deprecating Intel processor support. So the build should work around that with FEATURE_APX ifdefs or similar. If GCC and musl don't support an updated assembler yet, then I guess the change to symbolic code can't be made.

But I do have another open to discuss, I've logged the details in context.cpp. It would be much appreciated if you could share some thoughts.

This is a question about CONTEXT handling in the PAL -- @janvorli or @jkotas might be better to answer.

Now that we still have dependency on GCC and musl, we can let the raw byte code stay for a little longer. But I can still cover the needed changes for renaming and context copy in this PR

[Copilot]

Pull Request Overview

This PR renames extended registers from Egprx to Rx and fixes the copy logic for the CONTEXT structure related to AVX512 and APX handling.

• Renamed register fields from Egpr16–Egpr31 to R16–R31 in the PAL header.
• Updated memcpy calls in context.cpp to use the new register naming.
• Adjusted the assignment operator to separate APX register copying while handling AVX512.

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/coreclr/pal/src/thread/context.cpp	Updated memcpy calls and assignment operator logic to reflect register renaming and fix copy issues.
src/coreclr/pal/inc/pal.h	Renamed structure members from Egpr16–Egpr31 to R16–R31.

Comments suppressed due to low confidence (1)

src/coreclr/pal/inc/pal.h:1523

• [nitpick] The register fields have been renamed to 'R16-R31'; please verify that all related code references are updated accordingly.

DWORD64 R16;

[Ruihan-Yin]

failures look irrelevant, rerunning CI
@dotnet/intel for review

[Ruihan-Yin]

Hi @BruceForstall, could you please give this another review? Thanks!

[tannergooding]

LGTM. @janvorli or @jkotas should also sign-off since this is a PAL side change

[janvorli]

LGTM, thank you!

[Ruihan-Yin]

resolving the comments from #104637.

renamed Egprx to Rx.

Fixed the copy logic for CONTEXT data structure, now it should be able to correctly handle the cases with Avx512 and APX.

[Ruihan-Yin]

Hi @BruceForstall, I made the changes to revert the raw byte code in contetx2.S. Looks like some builds are still failing: OSX/tvOS, linux with GCC and musl.

Are these in this location because it mimics the layout of XSAVE? Or is it arbitrary? Why are these named "Egpr16" instead of just "R16"?

Also regarding this question, I have renamed the registers, and the layout should be arbitrary, we use __cpuid(0D, featureIndex) to query the size and offset of the XSTATE feature, and then load/store them into a abstracted data structure context. Detail behavior is defined in CONTEXTToNativeContext in context.cpp. So I think we don't need to change the layout.

But I do have another open to discuss, I've logged the details in context.cpp. It would be much appreciated if you could share some thoughts.

[BruceForstall]

I presume we will never support APX on OSX/tvOS or any Apple product, since they are actively deprecating Intel processor support. So the build should work around that with FEATURE_APX ifdefs or similar. If GCC and musl don't support an updated assembler yet, then I guess the change to symbolic code can't be made.

But I do have another open to discuss, I've logged the details in context.cpp. It would be much appreciated if you could share some thoughts.

This is a question about CONTEXT handling in the PAL -- @janvorli or @jkotas might be better to answer.

[janvorli]

@Ruihan-Yin there is no need to copy the contents of the CONTEXT in one block. You can copy the APX part separately. It was just a convenience when there was one extra block, so we could do a single copy.

[Ruihan-Yin]

@Ruihan-Yin there is no need to copy the contents of the CONTEXT in one block. You can copy the APX part separately. It was just a convenience when there was one extra block, so we could do a single copy.

Thanks for the clarification, I will make the changes accordingly.

[Ruihan-Yin]

I presume we will never support APX on OSX/tvOS or any Apple product, since they are actively deprecating Intel processor support. So the build should work around that with FEATURE_APX ifdefs or similar. If GCC and musl don't support an updated assembler yet, then I guess the change to symbolic code can't be made.

But I do have another open to discuss, I've logged the details in context.cpp. It would be much appreciated if you could share some thoughts.

This is a question about CONTEXT handling in the PAL -- @janvorli or @jkotas might be better to answer.

Now that we still have dependency on GCC and musl, we can let the raw byte code stay for a little longer. But I can still cover the needed changes for renaming and context copy in this PR

[Copilot]

Pull Request Overview

This PR renames extended registers from Egprx to Rx and fixes the copy logic for the CONTEXT structure related to AVX512 and APX handling.

• Renamed register fields from Egpr16–Egpr31 to R16–R31 in the PAL header.
• Updated memcpy calls in context.cpp to use the new register naming.
• Adjusted the assignment operator to separate APX register copying while handling AVX512.

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/coreclr/pal/src/thread/context.cpp	Updated memcpy calls and assignment operator logic to reflect register renaming and fix copy issues.
src/coreclr/pal/inc/pal.h	Renamed structure members from Egpr16–Egpr31 to R16–R31.

Comments suppressed due to low confidence (1)

src/coreclr/pal/inc/pal.h:1523

• [nitpick] The register fields have been renamed to 'R16-R31'; please verify that all related code references are updated accordingly.

DWORD64 R16;

[Ruihan-Yin]

failures look irrelevant, rerunning CI
@dotnet/intel for review

[Ruihan-Yin]

Hi @BruceForstall, could you please give this another review? Thanks!

[tannergooding]

LGTM. @janvorli or @jkotas should also sign-off since this is a PAL side change

[janvorli]

LGTM, thank you!

[Ruihan-Yin]

resolving the comments from #104637.

renamed Egprx to Rx.

Fixed the copy logic for CONTEXT data structure, now it should be able to correctly handle the cases with Avx512 and APX.

[Ruihan-Yin]

Hi @BruceForstall, I made the changes to revert the raw byte code in contetx2.S. Looks like some builds are still failing: OSX/tvOS, linux with GCC and musl.

Are these in this location because it mimics the layout of XSAVE? Or is it arbitrary? Why are these named "Egpr16" instead of just "R16"?

Also regarding this question, I have renamed the registers, and the layout should be arbitrary, we use __cpuid(0D, featureIndex) to query the size and offset of the XSTATE feature, and then load/store them into a abstracted data structure context. Detail behavior is defined in CONTEXTToNativeContext in context.cpp. So I think we don't need to change the layout.

But I do have another open to discuss, I've logged the details in context.cpp. It would be much appreciated if you could share some thoughts.

[BruceForstall]

I presume we will never support APX on OSX/tvOS or any Apple product, since they are actively deprecating Intel processor support. So the build should work around that with FEATURE_APX ifdefs or similar. If GCC and musl don't support an updated assembler yet, then I guess the change to symbolic code can't be made.

But I do have another open to discuss, I've logged the details in context.cpp. It would be much appreciated if you could share some thoughts.

This is a question about CONTEXT handling in the PAL -- @janvorli or @jkotas might be better to answer.

[janvorli]

@Ruihan-Yin there is no need to copy the contents of the CONTEXT in one block. You can copy the APX part separately. It was just a convenience when there was one extra block, so we could do a single copy.

[Ruihan-Yin]

@Ruihan-Yin there is no need to copy the contents of the CONTEXT in one block. You can copy the APX part separately. It was just a convenience when there was one extra block, so we could do a single copy.

Thanks for the clarification, I will make the changes accordingly.

[Ruihan-Yin]

I presume we will never support APX on OSX/tvOS or any Apple product, since they are actively deprecating Intel processor support. So the build should work around that with FEATURE_APX ifdefs or similar. If GCC and musl don't support an updated assembler yet, then I guess the change to symbolic code can't be made.

But I do have another open to discuss, I've logged the details in context.cpp. It would be much appreciated if you could share some thoughts.

This is a question about CONTEXT handling in the PAL -- @janvorli or @jkotas might be better to answer.

Now that we still have dependency on GCC and musl, we can let the raw byte code stay for a little longer. But I can still cover the needed changes for renaming and context copy in this PR

[Copilot]

Pull Request Overview

This PR renames extended registers from Egprx to Rx and fixes the copy logic for the CONTEXT structure related to AVX512 and APX handling.

• Renamed register fields from Egpr16–Egpr31 to R16–R31 in the PAL header.
• Updated memcpy calls in context.cpp to use the new register naming.
• Adjusted the assignment operator to separate APX register copying while handling AVX512.

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/coreclr/pal/src/thread/context.cpp	Updated memcpy calls and assignment operator logic to reflect register renaming and fix copy issues.
src/coreclr/pal/inc/pal.h	Renamed structure members from Egpr16–Egpr31 to R16–R31.

Comments suppressed due to low confidence (1)

src/coreclr/pal/inc/pal.h:1523

• [nitpick] The register fields have been renamed to 'R16-R31'; please verify that all related code references are updated accordingly.

DWORD64 R16;

[Ruihan-Yin]

failures look irrelevant, rerunning CI
@dotnet/intel for review

[Ruihan-Yin]

Hi @BruceForstall, could you please give this another review? Thanks!

[tannergooding]

LGTM. @janvorli or @jkotas should also sign-off since this is a PAL side change

[janvorli]

LGTM, thank you!

[Ruihan-Yin]

resolving the comments from #104637.

renamed Egprx to Rx.

Fixed the copy logic for CONTEXT data structure, now it should be able to correctly handle the cases with Avx512 and APX.

[Ruihan-Yin]

Hi @BruceForstall, I made the changes to revert the raw byte code in contetx2.S. Looks like some builds are still failing: OSX/tvOS, linux with GCC and musl.

Are these in this location because it mimics the layout of XSAVE? Or is it arbitrary? Why are these named "Egpr16" instead of just "R16"?

Also regarding this question, I have renamed the registers, and the layout should be arbitrary, we use __cpuid(0D, featureIndex) to query the size and offset of the XSTATE feature, and then load/store them into a abstracted data structure context. Detail behavior is defined in CONTEXTToNativeContext in context.cpp. So I think we don't need to change the layout.

But I do have another open to discuss, I've logged the details in context.cpp. It would be much appreciated if you could share some thoughts.

[BruceForstall]

I presume we will never support APX on OSX/tvOS or any Apple product, since they are actively deprecating Intel processor support. So the build should work around that with FEATURE_APX ifdefs or similar. If GCC and musl don't support an updated assembler yet, then I guess the change to symbolic code can't be made.

But I do have another open to discuss, I've logged the details in context.cpp. It would be much appreciated if you could share some thoughts.

This is a question about CONTEXT handling in the PAL -- @janvorli or @jkotas might be better to answer.

[janvorli]

@Ruihan-Yin there is no need to copy the contents of the CONTEXT in one block. You can copy the APX part separately. It was just a convenience when there was one extra block, so we could do a single copy.

[Ruihan-Yin]

@Ruihan-Yin there is no need to copy the contents of the CONTEXT in one block. You can copy the APX part separately. It was just a convenience when there was one extra block, so we could do a single copy.

Thanks for the clarification, I will make the changes accordingly.

[Ruihan-Yin]

I presume we will never support APX on OSX/tvOS or any Apple product, since they are actively deprecating Intel processor support. So the build should work around that with FEATURE_APX ifdefs or similar. If GCC and musl don't support an updated assembler yet, then I guess the change to symbolic code can't be made.

But I do have another open to discuss, I've logged the details in context.cpp. It would be much appreciated if you could share some thoughts.

This is a question about CONTEXT handling in the PAL -- @janvorli or @jkotas might be better to answer.

Now that we still have dependency on GCC and musl, we can let the raw byte code stay for a little longer. But I can still cover the needed changes for renaming and context copy in this PR

[Copilot]

Pull Request Overview

This PR renames extended registers from Egprx to Rx and fixes the copy logic for the CONTEXT structure related to AVX512 and APX handling.

• Renamed register fields from Egpr16–Egpr31 to R16–R31 in the PAL header.
• Updated memcpy calls in context.cpp to use the new register naming.
• Adjusted the assignment operator to separate APX register copying while handling AVX512.

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/coreclr/pal/src/thread/context.cpp	Updated memcpy calls and assignment operator logic to reflect register renaming and fix copy issues.
src/coreclr/pal/inc/pal.h	Renamed structure members from Egpr16–Egpr31 to R16–R31.

Comments suppressed due to low confidence (1)

src/coreclr/pal/inc/pal.h:1523

• [nitpick] The register fields have been renamed to 'R16-R31'; please verify that all related code references are updated accordingly.

DWORD64 R16;

[Ruihan-Yin]

failures look irrelevant, rerunning CI
@dotnet/intel for review

[Ruihan-Yin]

Hi @BruceForstall, could you please give this another review? Thanks!

[tannergooding]

LGTM. @janvorli or @jkotas should also sign-off since this is a PAL side change

[janvorli]

LGTM, thank you!

[Ruihan-Yin]

resolving the comments from #104637.

renamed Egprx to Rx.

Fixed the copy logic for CONTEXT data structure, now it should be able to correctly handle the cases with Avx512 and APX.

[Ruihan-Yin]

Hi @BruceForstall, I made the changes to revert the raw byte code in contetx2.S. Looks like some builds are still failing: OSX/tvOS, linux with GCC and musl.

Are these in this location because it mimics the layout of XSAVE? Or is it arbitrary? Why are these named "Egpr16" instead of just "R16"?

Also regarding this question, I have renamed the registers, and the layout should be arbitrary, we use __cpuid(0D, featureIndex) to query the size and offset of the XSTATE feature, and then load/store them into a abstracted data structure context. Detail behavior is defined in CONTEXTToNativeContext in context.cpp. So I think we don't need to change the layout.

But I do have another open to discuss, I've logged the details in context.cpp. It would be much appreciated if you could share some thoughts.

[BruceForstall]

I presume we will never support APX on OSX/tvOS or any Apple product, since they are actively deprecating Intel processor support. So the build should work around that with FEATURE_APX ifdefs or similar. If GCC and musl don't support an updated assembler yet, then I guess the change to symbolic code can't be made.

But I do have another open to discuss, I've logged the details in context.cpp. It would be much appreciated if you could share some thoughts.

This is a question about CONTEXT handling in the PAL -- @janvorli or @jkotas might be better to answer.

[janvorli]

@Ruihan-Yin there is no need to copy the contents of the CONTEXT in one block. You can copy the APX part separately. It was just a convenience when there was one extra block, so we could do a single copy.

[Ruihan-Yin]

@Ruihan-Yin there is no need to copy the contents of the CONTEXT in one block. You can copy the APX part separately. It was just a convenience when there was one extra block, so we could do a single copy.

Thanks for the clarification, I will make the changes accordingly.

[Ruihan-Yin]

I presume we will never support APX on OSX/tvOS or any Apple product, since they are actively deprecating Intel processor support. So the build should work around that with FEATURE_APX ifdefs or similar. If GCC and musl don't support an updated assembler yet, then I guess the change to symbolic code can't be made.

But I do have another open to discuss, I've logged the details in context.cpp. It would be much appreciated if you could share some thoughts.

This is a question about CONTEXT handling in the PAL -- @janvorli or @jkotas might be better to answer.

Now that we still have dependency on GCC and musl, we can let the raw byte code stay for a little longer. But I can still cover the needed changes for renaming and context copy in this PR

[Copilot]

Pull Request Overview

This PR renames extended registers from Egprx to Rx and fixes the copy logic for the CONTEXT structure related to AVX512 and APX handling.

• Renamed register fields from Egpr16–Egpr31 to R16–R31 in the PAL header.
• Updated memcpy calls in context.cpp to use the new register naming.
• Adjusted the assignment operator to separate APX register copying while handling AVX512.

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/coreclr/pal/src/thread/context.cpp	Updated memcpy calls and assignment operator logic to reflect register renaming and fix copy issues.
src/coreclr/pal/inc/pal.h	Renamed structure members from Egpr16–Egpr31 to R16–R31.

Comments suppressed due to low confidence (1)

src/coreclr/pal/inc/pal.h:1523

• [nitpick] The register fields have been renamed to 'R16-R31'; please verify that all related code references are updated accordingly.

DWORD64 R16;

[Ruihan-Yin]

failures look irrelevant, rerunning CI
@dotnet/intel for review

[Ruihan-Yin]

Hi @BruceForstall, could you please give this another review? Thanks!

[tannergooding]

LGTM. @janvorli or @jkotas should also sign-off since this is a PAL side change

[janvorli]

LGTM, thank you!

[Ruihan-Yin]

resolving the comments from #104637.

renamed Egprx to Rx.

Fixed the copy logic for CONTEXT data structure, now it should be able to correctly handle the cases with Avx512 and APX.

[Ruihan-Yin]

Hi @BruceForstall, I made the changes to revert the raw byte code in contetx2.S. Looks like some builds are still failing: OSX/tvOS, linux with GCC and musl.

Are these in this location because it mimics the layout of XSAVE? Or is it arbitrary? Why are these named "Egpr16" instead of just "R16"?

Also regarding this question, I have renamed the registers, and the layout should be arbitrary, we use __cpuid(0D, featureIndex) to query the size and offset of the XSTATE feature, and then load/store them into a abstracted data structure context. Detail behavior is defined in CONTEXTToNativeContext in context.cpp. So I think we don't need to change the layout.

But I do have another open to discuss, I've logged the details in context.cpp. It would be much appreciated if you could share some thoughts.

[BruceForstall]

I presume we will never support APX on OSX/tvOS or any Apple product, since they are actively deprecating Intel processor support. So the build should work around that with FEATURE_APX ifdefs or similar. If GCC and musl don't support an updated assembler yet, then I guess the change to symbolic code can't be made.

But I do have another open to discuss, I've logged the details in context.cpp. It would be much appreciated if you could share some thoughts.

This is a question about CONTEXT handling in the PAL -- @janvorli or @jkotas might be better to answer.

[janvorli]

@Ruihan-Yin there is no need to copy the contents of the CONTEXT in one block. You can copy the APX part separately. It was just a convenience when there was one extra block, so we could do a single copy.

[Ruihan-Yin]

@Ruihan-Yin there is no need to copy the contents of the CONTEXT in one block. You can copy the APX part separately. It was just a convenience when there was one extra block, so we could do a single copy.

Thanks for the clarification, I will make the changes accordingly.

[Ruihan-Yin]

I presume we will never support APX on OSX/tvOS or any Apple product, since they are actively deprecating Intel processor support. So the build should work around that with FEATURE_APX ifdefs or similar. If GCC and musl don't support an updated assembler yet, then I guess the change to symbolic code can't be made.

But I do have another open to discuss, I've logged the details in context.cpp. It would be much appreciated if you could share some thoughts.

This is a question about CONTEXT handling in the PAL -- @janvorli or @jkotas might be better to answer.

Now that we still have dependency on GCC and musl, we can let the raw byte code stay for a little longer. But I can still cover the needed changes for renaming and context copy in this PR

[Copilot]

Pull Request Overview

This PR renames extended registers from Egprx to Rx and fixes the copy logic for the CONTEXT structure related to AVX512 and APX handling.

• Renamed register fields from Egpr16–Egpr31 to R16–R31 in the PAL header.
• Updated memcpy calls in context.cpp to use the new register naming.
• Adjusted the assignment operator to separate APX register copying while handling AVX512.

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/coreclr/pal/src/thread/context.cpp	Updated memcpy calls and assignment operator logic to reflect register renaming and fix copy issues.
src/coreclr/pal/inc/pal.h	Renamed structure members from Egpr16–Egpr31 to R16–R31.

Comments suppressed due to low confidence (1)

src/coreclr/pal/inc/pal.h:1523

• [nitpick] The register fields have been renamed to 'R16-R31'; please verify that all related code references are updated accordingly.

DWORD64 R16;

[Ruihan-Yin]

failures look irrelevant, rerunning CI
@dotnet/intel for review

[Ruihan-Yin]

Hi @BruceForstall, could you please give this another review? Thanks!

[tannergooding]

LGTM. @janvorli or @jkotas should also sign-off since this is a PAL side change

[janvorli]

LGTM, thank you!