You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Dec 22, 2021. It is now read-only.
Repository navigation
This repository was archived by the owner on Dec 22, 2021. It is now read-only.
To make it easier to track the remaining proposals it would be great to close the PRs that we voted against or mark PRs that are known to be post-MVP with the relevant tag. I'm not sure if there are other instructions beyond the 4 above that still need discussion before phase 4 or not?
I've added a needs discussion label to the outstanding PRs that do not have a resolution. The issues #247 and #374 haven't seen much discussion of late, and the lowering for #395 is not convincing for late stage inclusion though prototyping and benchmarking efforts are in progress. I'll be adding votes to the PRs not included in the agenda shortly, and we can ratify them in the meeting if necessary.
@dtig I'm working on the testing and benchmarking now with respect to #395, but am not sure how the lowering is not convincing if the benchmarks pan out. On x86/x64, it's single instruction for all of the unsigned variants, and 2 instructions for all of the signed variants. The 2 instruction variants perform as well as the single instruction ones (according to LLVM-MCA) because the arithmetic shift isn't competitive with the shuffle ops.
I'm definitely curious to see how it performs on A64, but want to finish the x64 testing first.
@omnisip Sorry, my comments above are not very clear, I've followed up on #395. I'm aware of the code-gen lowerings, I was a reviewer for the patch that introduced them.
Activity
zeux commentedon Feb 2, 2021
To make it easier to track the remaining proposals it would be great to close the PRs that we voted against or mark PRs that are known to be post-MVP with the relevant tag. I'm not sure if there are other instructions beyond the 4 above that still need discussion before phase 4 or not?
dtig commentedon Feb 2, 2021
I've added a
needs discussionlabel to the outstanding PRs that do not have a resolution. The issues #247 and #374 haven't seen much discussion of late, and the lowering for #395 is not convincing for late stage inclusion though prototyping and benchmarking efforts are in progress. I'll be adding votes to the PRs not included in the agenda shortly, and we can ratify them in the meeting if necessary.omnisip commentedon Feb 2, 2021
@dtig I'm working on the testing and benchmarking now with respect to #395, but am not sure how the lowering is not convincing if the benchmarks pan out. On x86/x64, it's single instruction for all of the unsigned variants, and 2 instructions for all of the signed variants. The 2 instruction variants perform as well as the single instruction ones (according to LLVM-MCA) because the arithmetic shift isn't competitive with the shuffle ops.
I'm definitely curious to see how it performs on A64, but want to finish the x64 testing first.
omnisip commentedon Feb 2, 2021
Link for implemented prototype lowerings is here: https://chromium-review.googlesource.com/c/v8/v8/+/2617389/9/src/compiler/backend/x64/code-generator-x64.cc
dtig commentedon Feb 2, 2021
@omnisip Sorry, my comments above are not very clear, I've followed up on #395. I'm aware of the code-gen lowerings, I was a reviewer for the patch that introduced them.
tlively commentedon Feb 5, 2021
Thanks everyone! Here are the notes. Here are the decisions we came to:
We will merge:
We will not merge: