[Bug 272900] Mk/Uses/cpufeatures.mk - Framework helper for detecting CPU features/instructions

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272900

            Bug ID: 272900
           Summary: Mk/Uses/cpufeatures.mk - Framework helper for
                    detecting CPU features/instructions
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Ports Framework
          Assignee: portmgr@FreeBSD.org
          Reporter: diizzy@FreeBSD.org
                CC: fuz@FreeBSD.org, ports-bugs@FreeBSD.org,
                    yuri@freebsd.org, zirias@freebsd.org

Some upstream projects have specific optimized code paths which is great for
peformance however many times they're are not detected during run-time but
instead hardcoded and selected during configure/build stage. Currently we have
no way of detecting features but instead need to rely on OPTIONS which is a
pain and can lead to incorrect choices and/or broken binaries if wrong options
are selected.

Having a quick look grep returns the following and I'm quite sure we have more
potential users however maintainers haven't bothered because lack of framework
functionality.

grep -ir AVX --include Makefile /usr/ports/ | grep OPTIONS_DEFINE | wc -l
23
grep -ir SSE --include Makefile /usr/ports/ | grep OPTIONS_DEFINE | wc -l
63
grep -ir NEON --include Makefile /usr/ports/ | grep OPTIONS_DEFINE | wc -l
7
grep -ir VSX --include Makefile /usr/ports/ | grep OPTIONS_DEFINE | wc -l
2

There are at least two way of getting what features the compiler defines:

clang -v -march=native -E - </dev/null
echo | clang -E - -march=native -###

I'm not entirely sure on how to implement this though but I think most one
viable solution would to be adding a bunch of variables under a specific temple
and -march=native would follow CPUTYPE.

Target output looks like this:
-target-feature +crc32 -target-feature -fma4

CPU_FEAT_<FEATURE> crc32 would be CPU_FEAT_CRC32 and fma4 not initialized at
all since it's being disabled etc

Any ideas and/or input?

-- 
You are receiving this mail because:
You are on the CC list for the bug.