From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20510 invoked by alias); 9 Dec 2012 02:33:51 -0000 Received: (qmail 20258 invoked by uid 48); 9 Dec 2012 02:33:25 -0000 From: "siarhei.siamashka at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/55457] Having some predefined macros to get more information about gcc vector extensions capabilities would be nice Date: Sun, 09 Dec 2012 02:33:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: siarhei.siamashka at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-12/txt/msg00830.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55457 --- Comment #2 from Siarhei Siamashka 2012-12-09 02:33:24 UTC --- (In reply to comment #1) > The whole point of the gcc vector extensions is that you don't need to depend > on what the hardware can do under neath as it should produce good code in > either case. I think that you are a bit too idealistic and overlooking some practical implications: 1. GCC just does not generate really good code with vector extensions when there is no real SIMD backend. 2. There may be some high level algorithmic optimizations possible. For example, branches to skip calculations for some special cases. We really want to have these branches in scalar code, while SIMD can sacrifice the branches and gain a lot more performance from parallel processing. So right now GCC is forcing me and the other users to infest the code with ifdefs checking for __x86__, __amd64__, __arm__, __powerpc__, __SSE2__, __ALTIVEC__, __ARM_NEON__, etc. to disable the use of vector extensions when there is actually no real SIMD. It kinda defeats the purpose, because turns out that I need to know about the existence of all the CPU architectures supported by GCC and their SIMD implementations before I can expect that the code will work reasonably fast everywhere. Relying just on GCC vector extensions means non-portable code, which will not work with the other compilers. So in any case, everyone is likely to already have an alternative implementation written in standard C. Having two alternative implementations to select from, we want to be able to make a reasonably good guess about which implementation is going to be preferable for this particular build.