Add VectorTableList and TableVectorExtension intrinsics

[TamarChristinaArm]

Hi All,

This add VectorTableList and VectorTableExtension intrinsics
along with codegen and jit support for all TBX and TBL variants.

Implements the API approved part of #1277.

/CC @echesakovMSFT @tannergooding@CarolEidt

Thanks,
Tamar

[Dotnet-GitSync-Bot]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[TamarChristinaArm]

Codegen looks like this:

G_M16533_IG04:
FD4027A0 ldr d0, [fp,#72]
3DC00FB0 ldr q16, [fp,#48]
FD4017B1 ldr d17, [fp,#40]
0E111200 tbx v0.8b, {v16.8b}, v17.8b
FD000FA0 str d0, [fp,#24] // [V04 tmp1]
FD400FA0 ldr d0, [fp,#24] // [V04 tmp1]

[echesakov]

LGTM (with minor changes)

[echesakov]

Not related to Tamar's change but I am wondering once again whether we want to move this into some kind of table instead of defining the numbers in code? @BruceForstall@briansull

I spend non-trivial amount of time adding these numbers while working on #35379 and #33461 and I want either simplify the process for PerfScore or make it optional (i.e. remove the assert for unhandled cases and track the work for adding PerfScore numbers as a separate work item) since technically it's not require for the product.

I also see the benefits of moving this to table since if we want we can extend/define a new "table" for another microarchitecture - while now the numbers are "hardcoded" all over the place.

[BruceForstall]

I agree that making this table-driven would probably be simpler in the long run. And I'm ok with making it optional, to avoid blocking your forward progress on adding perf scores, although if we do that we should add GitHub issues to track known work (like perfscores needed for instructions X, Y, ...)

[echesakov]

Sounds good Bruce, I will open such issue to track this when I have another PR adding new instructions

[echesakov]

Just realized that since this PR adds new instruction to encoder CodeGen::genArm64EmitterUnitTests in codegenarm64.cpp also needs to be updated.

I am merging this anyway to avoid conflicts with #35612

@TamarChristinaArm can you please follow up on this later and add the unit tests?

Not sure why runtime (Installer Build and Test coreclr Windows_NT_x86 Debug) shows as In progress - it's finished here, ignoring...

[TamarChristinaArm]

@echesakovMSFT oops yes I completely forgot about the emitter tests. I'll send a PR today. Thanks!

[TamarChristinaArm]

Hi All,

This add VectorTableList and VectorTableExtension intrinsics
along with codegen and jit support for all TBX and TBL variants.

Implements the API approved part of #1277.

/CC @echesakovMSFT @tannergooding@CarolEidt

Thanks,
Tamar

[Dotnet-GitSync-Bot]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[TamarChristinaArm]

Codegen looks like this:

G_M16533_IG04:
FD4027A0 ldr d0, [fp,#72]
3DC00FB0 ldr q16, [fp,#48]
FD4017B1 ldr d17, [fp,#40]
0E111200 tbx v0.8b, {v16.8b}, v17.8b
FD000FA0 str d0, [fp,#24] // [V04 tmp1]
FD400FA0 ldr d0, [fp,#24] // [V04 tmp1]

[echesakov]

LGTM (with minor changes)

[echesakov]

Not related to Tamar's change but I am wondering once again whether we want to move this into some kind of table instead of defining the numbers in code? @BruceForstall@briansull

I spend non-trivial amount of time adding these numbers while working on #35379 and #33461 and I want either simplify the process for PerfScore or make it optional (i.e. remove the assert for unhandled cases and track the work for adding PerfScore numbers as a separate work item) since technically it's not require for the product.

I also see the benefits of moving this to table since if we want we can extend/define a new "table" for another microarchitecture - while now the numbers are "hardcoded" all over the place.

[BruceForstall]

I agree that making this table-driven would probably be simpler in the long run. And I'm ok with making it optional, to avoid blocking your forward progress on adding perf scores, although if we do that we should add GitHub issues to track known work (like perfscores needed for instructions X, Y, ...)

[echesakov]

Sounds good Bruce, I will open such issue to track this when I have another PR adding new instructions

[echesakov]

Just realized that since this PR adds new instruction to encoder CodeGen::genArm64EmitterUnitTests in codegenarm64.cpp also needs to be updated.

I am merging this anyway to avoid conflicts with #35612

@TamarChristinaArm can you please follow up on this later and add the unit tests?

Not sure why runtime (Installer Build and Test coreclr Windows_NT_x86 Debug) shows as In progress - it's finished here, ignoring...

[TamarChristinaArm]

@echesakovMSFT oops yes I completely forgot about the emitter tests. I'll send a PR today. Thanks!

[TamarChristinaArm]

Hi All,

This add VectorTableList and VectorTableExtension intrinsics
along with codegen and jit support for all TBX and TBL variants.

Implements the API approved part of #1277.

/CC @echesakovMSFT @tannergooding@CarolEidt

Thanks,
Tamar

[Dotnet-GitSync-Bot]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[TamarChristinaArm]

Codegen looks like this:

G_M16533_IG04:
FD4027A0 ldr d0, [fp,#72]
3DC00FB0 ldr q16, [fp,#48]
FD4017B1 ldr d17, [fp,#40]
0E111200 tbx v0.8b, {v16.8b}, v17.8b
FD000FA0 str d0, [fp,#24] // [V04 tmp1]
FD400FA0 ldr d0, [fp,#24] // [V04 tmp1]

[echesakov]

LGTM (with minor changes)

[echesakov]

Not related to Tamar's change but I am wondering once again whether we want to move this into some kind of table instead of defining the numbers in code? @BruceForstall@briansull

I spend non-trivial amount of time adding these numbers while working on #35379 and #33461 and I want either simplify the process for PerfScore or make it optional (i.e. remove the assert for unhandled cases and track the work for adding PerfScore numbers as a separate work item) since technically it's not require for the product.

I also see the benefits of moving this to table since if we want we can extend/define a new "table" for another microarchitecture - while now the numbers are "hardcoded" all over the place.

[BruceForstall]

I agree that making this table-driven would probably be simpler in the long run. And I'm ok with making it optional, to avoid blocking your forward progress on adding perf scores, although if we do that we should add GitHub issues to track known work (like perfscores needed for instructions X, Y, ...)

[echesakov]

Sounds good Bruce, I will open such issue to track this when I have another PR adding new instructions

[echesakov]

Just realized that since this PR adds new instruction to encoder CodeGen::genArm64EmitterUnitTests in codegenarm64.cpp also needs to be updated.

I am merging this anyway to avoid conflicts with #35612

@TamarChristinaArm can you please follow up on this later and add the unit tests?

Not sure why runtime (Installer Build and Test coreclr Windows_NT_x86 Debug) shows as In progress - it's finished here, ignoring...

[TamarChristinaArm]

@echesakovMSFT oops yes I completely forgot about the emitter tests. I'll send a PR today. Thanks!

[TamarChristinaArm]

Hi All,

This add VectorTableList and VectorTableExtension intrinsics
along with codegen and jit support for all TBX and TBL variants.

Implements the API approved part of #1277.

/CC @echesakovMSFT @tannergooding@CarolEidt

Thanks,
Tamar

[Dotnet-GitSync-Bot]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[TamarChristinaArm]

Codegen looks like this:

G_M16533_IG04:
FD4027A0 ldr d0, [fp,#72]
3DC00FB0 ldr q16, [fp,#48]
FD4017B1 ldr d17, [fp,#40]
0E111200 tbx v0.8b, {v16.8b}, v17.8b
FD000FA0 str d0, [fp,#24] // [V04 tmp1]
FD400FA0 ldr d0, [fp,#24] // [V04 tmp1]

[echesakov]

LGTM (with minor changes)

[echesakov]

Not related to Tamar's change but I am wondering once again whether we want to move this into some kind of table instead of defining the numbers in code? @BruceForstall@briansull

I spend non-trivial amount of time adding these numbers while working on #35379 and #33461 and I want either simplify the process for PerfScore or make it optional (i.e. remove the assert for unhandled cases and track the work for adding PerfScore numbers as a separate work item) since technically it's not require for the product.

I also see the benefits of moving this to table since if we want we can extend/define a new "table" for another microarchitecture - while now the numbers are "hardcoded" all over the place.

[BruceForstall]

I agree that making this table-driven would probably be simpler in the long run. And I'm ok with making it optional, to avoid blocking your forward progress on adding perf scores, although if we do that we should add GitHub issues to track known work (like perfscores needed for instructions X, Y, ...)

[echesakov]

Sounds good Bruce, I will open such issue to track this when I have another PR adding new instructions

[echesakov]

Just realized that since this PR adds new instruction to encoder CodeGen::genArm64EmitterUnitTests in codegenarm64.cpp also needs to be updated.

I am merging this anyway to avoid conflicts with #35612

@TamarChristinaArm can you please follow up on this later and add the unit tests?

Not sure why runtime (Installer Build and Test coreclr Windows_NT_x86 Debug) shows as In progress - it's finished here, ignoring...

[TamarChristinaArm]

@echesakovMSFT oops yes I completely forgot about the emitter tests. I'll send a PR today. Thanks!

[TamarChristinaArm]

Hi All,

This add VectorTableList and VectorTableExtension intrinsics
along with codegen and jit support for all TBX and TBL variants.

Implements the API approved part of #1277.

/CC @echesakovMSFT @tannergooding@CarolEidt

Thanks,
Tamar

[Dotnet-GitSync-Bot]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[TamarChristinaArm]

Codegen looks like this:

G_M16533_IG04:
FD4027A0 ldr d0, [fp,#72]
3DC00FB0 ldr q16, [fp,#48]
FD4017B1 ldr d17, [fp,#40]
0E111200 tbx v0.8b, {v16.8b}, v17.8b
FD000FA0 str d0, [fp,#24] // [V04 tmp1]
FD400FA0 ldr d0, [fp,#24] // [V04 tmp1]

[echesakov]

LGTM (with minor changes)

[echesakov]

Not related to Tamar's change but I am wondering once again whether we want to move this into some kind of table instead of defining the numbers in code? @BruceForstall@briansull

I spend non-trivial amount of time adding these numbers while working on #35379 and #33461 and I want either simplify the process for PerfScore or make it optional (i.e. remove the assert for unhandled cases and track the work for adding PerfScore numbers as a separate work item) since technically it's not require for the product.

I also see the benefits of moving this to table since if we want we can extend/define a new "table" for another microarchitecture - while now the numbers are "hardcoded" all over the place.

[BruceForstall]

I agree that making this table-driven would probably be simpler in the long run. And I'm ok with making it optional, to avoid blocking your forward progress on adding perf scores, although if we do that we should add GitHub issues to track known work (like perfscores needed for instructions X, Y, ...)

[echesakov]

Sounds good Bruce, I will open such issue to track this when I have another PR adding new instructions

[echesakov]

Just realized that since this PR adds new instruction to encoder CodeGen::genArm64EmitterUnitTests in codegenarm64.cpp also needs to be updated.

I am merging this anyway to avoid conflicts with #35612

@TamarChristinaArm can you please follow up on this later and add the unit tests?

Not sure why runtime (Installer Build and Test coreclr Windows_NT_x86 Debug) shows as In progress - it's finished here, ignoring...

[TamarChristinaArm]

@echesakovMSFT oops yes I completely forgot about the emitter tests. I'll send a PR today. Thanks!

[TamarChristinaArm]

Hi All,

This add VectorTableList and VectorTableExtension intrinsics
along with codegen and jit support for all TBX and TBL variants.

Implements the API approved part of #1277.

/CC @echesakovMSFT @tannergooding@CarolEidt

Thanks,
Tamar

[Dotnet-GitSync-Bot]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[TamarChristinaArm]

Codegen looks like this:

G_M16533_IG04:
FD4027A0 ldr d0, [fp,#72]
3DC00FB0 ldr q16, [fp,#48]
FD4017B1 ldr d17, [fp,#40]
0E111200 tbx v0.8b, {v16.8b}, v17.8b
FD000FA0 str d0, [fp,#24] // [V04 tmp1]
FD400FA0 ldr d0, [fp,#24] // [V04 tmp1]

[echesakov]

LGTM (with minor changes)

[echesakov]

Not related to Tamar's change but I am wondering once again whether we want to move this into some kind of table instead of defining the numbers in code? @BruceForstall@briansull

I spend non-trivial amount of time adding these numbers while working on #35379 and #33461 and I want either simplify the process for PerfScore or make it optional (i.e. remove the assert for unhandled cases and track the work for adding PerfScore numbers as a separate work item) since technically it's not require for the product.

I also see the benefits of moving this to table since if we want we can extend/define a new "table" for another microarchitecture - while now the numbers are "hardcoded" all over the place.

[BruceForstall]

I agree that making this table-driven would probably be simpler in the long run. And I'm ok with making it optional, to avoid blocking your forward progress on adding perf scores, although if we do that we should add GitHub issues to track known work (like perfscores needed for instructions X, Y, ...)

[echesakov]

Sounds good Bruce, I will open such issue to track this when I have another PR adding new instructions

[echesakov]

Just realized that since this PR adds new instruction to encoder CodeGen::genArm64EmitterUnitTests in codegenarm64.cpp also needs to be updated.

I am merging this anyway to avoid conflicts with #35612

@TamarChristinaArm can you please follow up on this later and add the unit tests?

Not sure why runtime (Installer Build and Test coreclr Windows_NT_x86 Debug) shows as In progress - it's finished here, ignoring...

[TamarChristinaArm]

@echesakovMSFT oops yes I completely forgot about the emitter tests. I'll send a PR today. Thanks!

[TamarChristinaArm]

Hi All,

This add VectorTableList and VectorTableExtension intrinsics
along with codegen and jit support for all TBX and TBL variants.

Implements the API approved part of #1277.

/CC @echesakovMSFT @tannergooding@CarolEidt

Thanks,
Tamar

[Dotnet-GitSync-Bot]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[TamarChristinaArm]

Codegen looks like this:

G_M16533_IG04:
FD4027A0 ldr d0, [fp,#72]
3DC00FB0 ldr q16, [fp,#48]
FD4017B1 ldr d17, [fp,#40]
0E111200 tbx v0.8b, {v16.8b}, v17.8b
FD000FA0 str d0, [fp,#24] // [V04 tmp1]
FD400FA0 ldr d0, [fp,#24] // [V04 tmp1]

[echesakov]

LGTM (with minor changes)

[echesakov]

Not related to Tamar's change but I am wondering once again whether we want to move this into some kind of table instead of defining the numbers in code? @BruceForstall@briansull

I spend non-trivial amount of time adding these numbers while working on #35379 and #33461 and I want either simplify the process for PerfScore or make it optional (i.e. remove the assert for unhandled cases and track the work for adding PerfScore numbers as a separate work item) since technically it's not require for the product.

I also see the benefits of moving this to table since if we want we can extend/define a new "table" for another microarchitecture - while now the numbers are "hardcoded" all over the place.

[BruceForstall]

I agree that making this table-driven would probably be simpler in the long run. And I'm ok with making it optional, to avoid blocking your forward progress on adding perf scores, although if we do that we should add GitHub issues to track known work (like perfscores needed for instructions X, Y, ...)

[echesakov]

Sounds good Bruce, I will open such issue to track this when I have another PR adding new instructions

[echesakov]

Just realized that since this PR adds new instruction to encoder CodeGen::genArm64EmitterUnitTests in codegenarm64.cpp also needs to be updated.

I am merging this anyway to avoid conflicts with #35612

@TamarChristinaArm can you please follow up on this later and add the unit tests?

Not sure why runtime (Installer Build and Test coreclr Windows_NT_x86 Debug) shows as In progress - it's finished here, ignoring...

[TamarChristinaArm]

@echesakovMSFT oops yes I completely forgot about the emitter tests. I'll send a PR today. Thanks!

[TamarChristinaArm]

Hi All,

This add VectorTableList and VectorTableExtension intrinsics
along with codegen and jit support for all TBX and TBL variants.

Implements the API approved part of #1277.

/CC @echesakovMSFT @tannergooding@CarolEidt

Thanks,
Tamar

[Dotnet-GitSync-Bot]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[TamarChristinaArm]

Codegen looks like this:

G_M16533_IG04:
FD4027A0 ldr d0, [fp,#72]
3DC00FB0 ldr q16, [fp,#48]
FD4017B1 ldr d17, [fp,#40]
0E111200 tbx v0.8b, {v16.8b}, v17.8b
FD000FA0 str d0, [fp,#24] // [V04 tmp1]
FD400FA0 ldr d0, [fp,#24] // [V04 tmp1]

[echesakov]

LGTM (with minor changes)

[echesakov]

Not related to Tamar's change but I am wondering once again whether we want to move this into some kind of table instead of defining the numbers in code? @BruceForstall@briansull

I spend non-trivial amount of time adding these numbers while working on #35379 and #33461 and I want either simplify the process for PerfScore or make it optional (i.e. remove the assert for unhandled cases and track the work for adding PerfScore numbers as a separate work item) since technically it's not require for the product.

I also see the benefits of moving this to table since if we want we can extend/define a new "table" for another microarchitecture - while now the numbers are "hardcoded" all over the place.

[BruceForstall]

I agree that making this table-driven would probably be simpler in the long run. And I'm ok with making it optional, to avoid blocking your forward progress on adding perf scores, although if we do that we should add GitHub issues to track known work (like perfscores needed for instructions X, Y, ...)

[echesakov]

Sounds good Bruce, I will open such issue to track this when I have another PR adding new instructions

[echesakov]

Just realized that since this PR adds new instruction to encoder CodeGen::genArm64EmitterUnitTests in codegenarm64.cpp also needs to be updated.

I am merging this anyway to avoid conflicts with #35612

@TamarChristinaArm can you please follow up on this later and add the unit tests?

Not sure why runtime (Installer Build and Test coreclr Windows_NT_x86 Debug) shows as In progress - it's finished here, ignoring...

[TamarChristinaArm]

@echesakovMSFT oops yes I completely forgot about the emitter tests. I'll send a PR today. Thanks!