2013/6/14 dw <[email protected]>: > > 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. > > The fact that it would be a "big clean up" should probably have been listed > in the "cons." While I believe having all the bits of MSVC's intrinsics in > one place is the best plan, there's no denying that it would be a big > change. And big changes usually have consequences.
Well, I think it is indeed a good thing to have all intrinsics in one headers, but I am not that sure if it is wise to use intrin.h header directly for it. I would prefer to have a private implementation-header, which gets included by intrin.h header. > > why do we have intrins in crt. > > MSVC also has library functions for some of the routines. Among other > things, this allows people to create pointers to them. Well, gcc has also option to disable inline-functions. So I see it as manadatory to provide also all intrinsic-functions additional in library. Right now we add them to libkernel32.a library. > 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. Right, that is a pretty important point we need to consider. > This presents some implementation questions. > > Consider: I can create my own cpp file with zero headers and put a prototype > for __stosb (which is always supposed to get inlined) in it. MSVC will > still generate the inline code for this because the "implementation" is in > the compiler itself. This is not an option in GCC. Correct, see above the reason for having library-implementation for all of them. It is true that MS exports some of them, but it is more profitable for gcc-version to provide a static-version. By this later optimization-passes could do some benefits (like LTO). > If someone places a prototype in some other file, how can we get the inline > version there without #including <intrin.h>? Under the current > implementation, this would 'work' for routines like __stosb because the > symbol would eventually get resolved from the library. However presumably > this would be done with a "call" rather than inlined. See above. > If we choose to use the approach I'm describing, one consequence would be > that if you want to use MSVC's intrinsic functions in gcc, you would have to > #include <intrin.h>. That's not acceptable. > > I'd say that, ideally we'd put everything in #ifdef __MINGW_INTRIN_INLINE. > > Ok by me. I just chose __CRT_INLINE because it seemed to be what other code > was using. > > dw > Kai ------------------------------------------------------------------------------ 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
