The working assumption is to start with the existing GCC headers from ./gcc/config/i386/, then convert them to PowerISA and add them to ./gcc/config/rs6000/. I assume we will replicate the existing header structure and retain the existing header file and intrinsic names. This also allows us to reuse existing DejaGNU test cases from ./gcc/testsuite/gcc.target/i386, modify them as needed for the POWER target, and add them to ./gcc/testsuite/gcc.target/powerpc. We can be flexible on the sequence that headers/intrinsics and test cases are ported.  This should be based on customer need and resolving internal dependencies.  This implies an oldest-to-newest / bottoms-up (MMX, SSE, SSE2, …) strategy. The assumption is, existing community and user application codes, are more likely to have optimized code for previous generation ubiquitous (SSE, SSE2, ...) processors than the latest (and rare) SkyLake AVX512. I would start with an existing header from the current GCC  ./gcc/config/i386/ and copy the header comment (including FSF copyright) down to any vector typedefs used in the API or implementation. Skip the Intel intrinsic implementation code for now, but add the ending #end if matching the headers conditional guard against multiple inclusion. You can add additional #include's as needed. For example: #include /* We need definitions from the SSE header files. */ #include /* The Intel API is flexible enough that we must allow aliasing with other vector types, and their scalar components. */ typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__)); /* Internal data types for implementing the intrinsics. */ typedef __vector float __v4sf; /* more typedefs. */ /* The intrinsic implmentations go here. */ #endif /* EMMINTRIN_H_ */]]> The interface typedef (__m128) uses the GCC vector builtin extension syntax, while the internal typedef (__v4sf) uses the altivec vector extension syntax. This allows the internal typedefs to work correctly with the PowerPC overloaded vector builtins. Also we use the __vector (vs vector) type prefix to avoid name space conflicts with C++. Then you can start adding small groups of related intrinsic implementations to the header to be compiled and  examine the generated code. Once you have what looks like reasonable code you can grep through  ./gcc/testsuite/gcc.target/i386 for examples using the intrinsic names you just added. You should be able to find functional tests for most X86 intrinsics. The GCC testsuite uses the DejaGNU  test framework as documented in the GNU Compiler Collection (GCC) Internals manual. GCC adds its own DejaGNU directives and extensions, that are embedded in the testsuite source as comments.  Some are platform specific and will need to be adjusted for tests that are ported to our platform. For example should become something like Repeat this process until you have equivalent DejaGNU test implementations for all the intrinsics in that header and associated test cases that execute without error.