Longest patchset ever ;-p OK, so I got trolled into doing cpuflags porting and here is the result. After applying the whole series, no more old school assembly remains. Or, at least, nothing that does not use cpuflags.
Note that some of this conflicts with or duplicates some recent work from Ronald and Justin. We'll work it out, I'm sending this out so we can coordinate better. The first batch of patches are preliminaries. [PATCH 01/45] x86: Use consistent 3dnowext file/function/macro name suffixes [PATCH 02/45] x86: build: replace mmx2 by mmxext [PATCH 03/45] x86: mmx2 ---> mmxext in comments and messages [PATCH 04/45] x86: MMX2 ---> MMXEXT in macro names [PATCH 05/45] x86: mmx2 ---> mmxext in variable names [PATCH 06/45] x86: mmx2 ---> mmxext in function names [PATCH 07/45] x86: mmx2 ---> mmxext in asm constructs With cpuflags, function name suffixes are dictated by the cpuflag. Currently there is a wild mix of names for 3dnow, 3dnowext and mmxext. I unified it all settling for 3dnowext and mmxext instead of 3dnow2 and mmx2. These are the actual names of the cpuflags as shown for example in /proc/cpuinfo. 3dnow2 and mmx2 are made-up names that appear to have originated in MPlayer or so. While googling around, I found no usage of those names outside of our project(s). That made me settle for the more official naming even though this entailed more changes. [PATCH 08/45] x86: include x86inc.asm in x86util.asm This is required by 29/45 onwards. [PATCH 09/45] x86: yasm: Use complete source path for macro helper %includes Again done for consistency, we had a mix of both forms. Adding the full path entails more changes than the other way around, but allows having files of the same basename in different directories, so it is IMO worthwhile. [PATCH 10/45] x86: ac3dsp: port to cpuflags [PATCH 11/45] x86: dct32: port to cpuflags [PATCH 12/45] x86: dsputil_yasm: port to cpuflags [PATCH 13/45] x86: dsputilenc_yasm: port to cpuflags [PATCH 14/45] x86: fmtconvert: port to cpuflags [PATCH 15/45] x86: h264_chromamc_10bit: drop pointless PAVG %define [PATCH 16/45] x86: Move optimization suffix to end of function names [PATCH 17/45] x86: h264_chromamc: port to cpuflags [PATCH 18/45] x86: h264_deblock: port to cpuflags [PATCH 19/45] x86: h264_idct: Rename x264_add8x4_idct_sse2 --> h264_add8x4_idct_sse2 [PATCH 20/45] x86: h264_idct: port to cpuflags [PATCH 21/45] x86: h264_intrapred_10bit: port to cpuflags [PATCH 22/45] x86: h264_intrapred: port to cpuflags [PATCH 23/45] x86: h264_qpel_10bit: port to cpuflags [PATCH 24/45] x86: h264_qpel_10bit: drop unused parameter from MC10/MC20/MC30 macros [PATCH 25/45] x86: h264_weight_10bit: port to cpuflags [PATCH 26/45] x86: h264_weight: port to cpuflags [PATCH 27/45] x86: vc1dsp: port to cpuflags Part 1 of the meat of this series, porting to cpuflags. [PATCH 28/45] x86: Drop no longer used and obsolete INIT_AVX macro At this point INIT_AVX can be eliminated, nothing still uses it. [PATCH 29/45] x86: fmtconvert: Refactor cvtps2pi emulation through cpuflags [PATCH 30/45] x86: vp8dsp: port FILTER_BILINEAR macro to cpuflags [PATCH 31/45] x86: proresdsp: improve SIGNEXTEND macro comments [PATCH 32/45] x86: PMINUB: port to cpuflags [PATCH 33/45] x86: PALIGNR: port to cpuflags [PATCH 34/45] x86: PABSW: port to cpuflags [PATCH 35/45] x86: PSIGNW: port to cpuflags [PATCH 36/45] x86: CLIPD: port to cpuflags [PATCH 37/45] x86: ABS1: port to cpuflags [PATCH 38/45] x86: ABS2: port to cpuflags [PATCH 39/45] x86: ABSB: port to cpuflags [PATCH 40/45] x86: ABSB2: port to cpuflags [PATCH 41/45] x86: Rename SPLATD macro to SPLATD_OFFSET [PATCH 42/45] x86: SPLATD: port to cpuflags [PATCH 43/45] x86: Refactor PSWAPD fallback implementations and port to cpuflags [PATCH 44/45] x86: Add PAVGB macro to abstract pavgb/pavgusb instruction via cpuflags This is the second part of the series. Now that all .asm files are switched to cpuflags the helper macros can be refactored as well. [PATCH 45/45] x86: fft_mmx: Refactor INTERL macro with cpuflags This one is still broken with 3dnow. I am mystified. Happy reviewing! Diego _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
