Skip to content

VectorOps: Simplify 256-bit VAddV#5745

Merged
Sonicadvance1 merged 1 commit into
FEX-Emu:mainfrom
lioncash:addv
Jul 15, 2026
Merged

VectorOps: Simplify 256-bit VAddV#5745
Sonicadvance1 merged 1 commit into
FEX-Emu:mainfrom
lioncash:addv

Conversation

@lioncash

@lioncash lioncash commented Jul 14, 2026

Copy link
Copy Markdown
Contributor

Didn't read the manual close enough on the first read when I dropped this in award.

addv(SubRegSize.Vector, VTMP2.Q(), Vector.Q());
addv(SubRegSize.Vector, VTMP1.Q(), VTMP1.Q());
add(SubRegSize.Vector, Dst.Q(), VTMP1.Q(), VTMP2.Q());
uaddv(SubRegSize.Vector, Dst.D(), Mask, Vector.Z());

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I don't think this exactly matches behaviour. Looks like this always zero extends smaller elements to be 64-bit, so overflow for something like 16-bit additions could return garbage in the upper 48-bits instead of truncating to a 16-bit scalar.

Which most operations immediately feed in to a VExtractToGPR so it can't see that, but something like PSADBWOpImpl isn't so it would be visible there.

Might want a unittest for the few instructions that /can/ overflow, and maybe a bool in the IR operation to force an element size mask for operations that need it? ptrue should be able to generate the mask, which will add a ptrue + mov pair if masking is absolutely required?

Didn't read the manual close enough on the first read award.
@Sonicadvance1
Sonicadvance1 merged commit 5ec8526 into FEX-Emu:main Jul 15, 2026
13 checks passed
@lioncash
lioncash deleted the addv branch July 15, 2026 16:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants