I'd like to discuss the entire purpose of the intrin.h file in gcc.
In response to my recent proposed patch re __faststorefence, Kai
remarked that making changes to intrin.h is something we should be
minimizing/avoiding. Until this point, I hadn't been aware that this
was a point of contention. But since the issue has come up, I think the
current usage of this file is not well thought out, and I'd like to
propose a change. Or at least provoke some discussion so *I* understand
what the purpose is.
Let's start by considering how this file is used by MSVC. MS has a
pretty good description of what they mean by "intrinsics" here
(http://msdn.microsoft.com/en-us/library/26td21ds%28v=vs.80%29.aspx). In
brief, intrinsics are similar to what gcc calls builtins. While all of
the intrinsics can be inlined, some of them are also available as
library functions. For functions that are available as both, you can
use #pragma intrinsic(FunctionName) to specifically request the
intrinsic version. Using the compiler switch /Oi enables the intrinsic
version for all intrinsics.
So how does this translate to gcc? Obviously the gcc compiler isn't
going to automatically generate any code for MS's intrinsics. Which
means that as part of making these functions available under gcc, the
implementation must be done somewhere. Looking at the current state of
mingw-w64, I see that some are implemented in winnt.h (like
__faststorefence), some are implemented in a library generated from
mingw-w64-crt\intrincs\*.c (like __rdtsc), some are in both (like
__stosb) and some aren't implemented at all (like __int2c).
What I'd like to propose is that all the functions that MS defines as
"only available as an intrinsic" should be defined (either as macros or
always_inline routines) at the bottom of intrin.h. Beneath that there
would be a separate section protected with a single #ifdef would contain
the intrinsic (inline) version of all the functions that are available
as both intrinsic or library. See outline at end of message.
*pros:*
- Allows using either intrinsic or library functions. The library
functions are likely to be useful for jump tables and the like.
- The MSVC "compiler intrinsics" are all defined in one place.
- You don't need to include "platform" files to get "compiler" routines.
- The definitions in intrin.h stay unmodified.
- We could remove the (redundant) compiler intrinsic definitions from
the platform files.
*cons:*
- This approach doesn't provide the ability to turn intrinsics on and
off individually like MS does (of course neither does what we have
now). This is essentially the same as using MS's /Oi or /Oi-.
- The intrin.h file gets modified as additional intrinsics are supported.
The intrin.h file I'm proposing would look something like this:
// All the existing __MACHINEX64 etc definitions here
// All the existing #define __REG* definitions here
// This block contains the definitions for all (implemented)
// "only available as intrinsic" functions.
__CRT_INLINE void __stosb...
// In this block, we put the intrinsic definitions of all the functions that
// can be either intrinsic or library. If __CRT__NO_INLINE is defined, we
// are going to use the lib version of the functions. Otherwise we use the
// definitions here.
#ifndef __CRT__NO_INLINE
#if (defined(_X86_) || defined(__x86_64))
// All the functions that work on both x86 and x64 here
__CRT_INLINE unsigned short _rotl16(...
#endif
#if defined(__x86_64))
// All the x64 only functions here
__CRT_INLINE __int64 _InterlockedDecrement64(...
#endif
#endif
dw
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
