steam-frame/FEX-Emu--FEX
1
0 Fork 0
mirror of https://github.com/FEX-Emu/FEX.git synced 2026-10-06 10:00:16 +02:00
Code Issues Packages Projects Releases 66 Wiki Activity
15,187 Commits 11 Branches 70 Tags
64a6da9aee4608eb4b1a1bb5d23d71a01b8fac30
Commit Graph
29 Commits
Author SHA1 Message Date
Ryan Houdek 0a41f470f8 InstcountCI: Update 2026-09-21 14:56:47 -07:00
Justin Becker 54b178d151 InstrCountCI: Bump disk cache version and regen 2026-09-17 11:25:52 -07:00
Ryan Houdek d06e98ed84 InstcountCI: Update 2026-09-15 16:40:55 -07:00
Pierre-Loup A. Griffais ae84606da2 InstcountCI: Update 2026-09-14 22:31:16 -07:00
Pierre-Loup A. Griffais c18deb0d0f InstcountCI: Update 2026-09-13 17:41:53 -07:00
Justin Becker 480308c021 Bump DiskCache version 2026-09-10 15:59:52 -07:00
Ryan Houdek 200f59ab70 InstcountCI: Update 2026-09-10 09:53:54 -07:00
Pierre-Loup A. Griffais cc5686de37 InstcountCI: Update 2026-09-07 22:51:31 -07:00
Pierre-Loup A. Griffais ffaa5d6316 InstcountCI: Update 2026-09-07 00:56:39 -07:00
Pierre-Loup A. Griffais 983c5defc1 InstcountCI: Update 2026-09-06 23:25:53 -07:00
Pierre-Loup A. Griffais 4a065ad1a2 InstcountCI: Update 2026-09-05 21:58:07 -07:00
Simon Scherer c5700cb0cc InstcountCI: Update 2026-09-04 17:03:46 +02:00
Simon Scherer 040d3115d2 InstcountCI: Update 2026-09-04 11:53:13 +02:00
Simon Scherer 96d65cd6bc InstcountCI: Update 2026-09-04 08:30:03 +02:00
Simon Scherer fd64ea54fe InstcountCI: Update 2026-09-04 07:32:09 +02:00
Simon Scherer 30e4650a8b InstcountCI: Update 2026-09-03 08:32:59 +02:00
Ryan Houdek fbf5187794 InstcountCI: Update 2026-09-02 18:35:36 -07:00
Ryan Houdek 20e9e2044e InstcountCI: Update 2026-09-02 17:15:36 -07:00
Justin Becker 3471ca67c4 Bump DiskCache version number 2026-09-02 16:40:17 -07:00
Simon Scherer bce8b13366 InstcountCI: Update 2026-09-02 07:47:24 +02:00
Pierre-Loup A. Griffais c01bfcd52f InstcountCI: Update 2026-09-01 03:51:12 -07:00
Ryan Houdek 1558a2c65d InstcountCI: Update 2026-08-31 19:23:20 -07:00
Pierre-Loup A. Griffais 0d3a5f96f0 InstcountCI: Update 2026-08-30 17:17:54 -07:00
Ryan Houdek b695c5ae11 InstCountCI: Update 
Only adds DiskCache version to json to ensure it's tracked. No asm
changes here.
 2026-08-30 14:26:45 -07:00
Alyssa Rosenzweig d935d25f0c InstCountCI: Update 
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
 2024-08-21 11:48:03 -04:00
Alyssa Rosenzweig 625d8ac177 InstCountCI: Update 
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
 2024-04-17 14:54:19 -04:00
Alyssa Rosenzweig ed59f73a65 InstCountCI: Update 
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
 2024-03-11 18:41:33 -04:00
Alyssa Rosenzweig bd4464bd5e InstructionCountCI: Remove Optimal flags 
Instruction count CI has transformed the way we work on FEX… I love the system
and want to make it better. there’s one part of instruction count CI that isn’t
so lovable: the problematic “optimal” flag on instructions.

There are several issues with this flag, both philosophical and practical.

– it is tedious to update the optimal flag when making an implementation
optimal. The effect of that is discouraging people from making instructions,
optimal, or encouraging people to fail to update the flag, and dilute the value
of it. Either way, since we care far more about optimal implementations, then we
do about updating the flag, clearly we should prioritize the implementation and
not the flag. This issue was not obvious at the outset, when instruction count,
CI was introduced, and still quite small. The problem magnified when we started
duplicating instructions in bulk for different combinations of CPU features
(flagm, AFP, etc.) that intern multiplies the manual work required to update the
flags by the corresponding constant factor. if it comes down to a choice between
removing this extra coverage and removing the flag, I think we all agree that
removing the flag is the lesser evil.

– The definition of “optimal” is fundamentally problematic. I have often
improved the instruction count of an instruction that was already “optimal”.
This is all kinds of silly, and calls into question whether there’s any value
whatsoever in the existing classifications of the flag. Furthermore, it is often
unknowable, whether an implementation really is optimal. Is it possible to
implement BZHI (with flag calculations) in fewer than eight instructions? We
don’t know, and it’s silly to pretend that we do.

– as a consequence of the problematic definitions , there are so many errors in
both directions that I don’t think there’s much value in preserving the existing
classification at the expense of +progress. Being able to say “32% of
instructions are translated optimally” is neat, but it really doesn’t tell us
anything whatsoever when you dig a little deeper.

So, as the flag is misleading at best and perhaps harmful at worst, let’s remove
it and make the instruction count CI, more useful overall. let’s let the
expected count and the assembly speak for themselves, and cut away the chaff. if
we want a meaningless number to report to management, we can instead calculate
the average blowup factor ;-)

Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
 2023-11-13 21:14:05 -04:00
Ryan Houdek 1acc038826 InstCountCI: Adds some multi instruction tests 
Some simple tests to showcase instructions that we can optimize.
- Back to back pushes could be optimized
- Back to back scalar vector operations can be optimized
- Show with AFP that back to back scalar is already optimal
   - Also ensures we don't break this stage.
 2023-10-10 16:45:39 -07:00