Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 02 Aug 2023 20:06:25 +0000
From:      bugzilla-noreply@freebsd.org
To:        ports-bugs@FreeBSD.org
Subject:   [Bug 272900] Mk/Uses/cpufeatures.mk - Framework helper for detecting CPU features/instructions
Message-ID:  <bug-272900-7788@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D272900

            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 h=
ave
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 opti=
ons
are selected.

Having a quick look grep returns the following and I'm quite sure we have m=
ore
potential users however maintainers haven't bothered because lack of framew=
ork
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=3Dnative -E - </dev/null
echo | clang -E - -march=3Dnative -###

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 te=
mple
and -march=3Dnative 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?

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-272900-7788>