On 06/14/13 09:43, dw wrote:
> 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.
I agree that intrin.h should receive some love. I have been doing some
work on it, but it was mostly fixing particular problems, I never had a
chance to do a big clean up.
Note, that big part of this file is in #if !defined(__GNUC__) and
instead GCC-provided headers are included on top of it. Those are fine
this way and GCC will take care of them. So your proposal applies only
remaining others.
I like the idea of having them as inline function. Even better than
__CRT_INLINE is __MINGW_INTRIN_INLINE, which was introduced with that
intention, but it never received widespread usage. If I was to decide,
I'd go with your idea. You'd have to ask Kai, why do we have intrins in crt.
Note that compatibility with MSVC is important here. For example, there
are a few intrins that are declared outside intrin.h. We need to make
sure that they still work without manual inclusion of intrin.h.
>
> *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
I'd say that, ideally we'd put everything in #ifdef __MINGW_INTRIN_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
Cheers,
Jacek
------------------------------------------------------------------------------
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
