This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Support some Intel intrinsics in the IA-64 backend


Hi Andreas,

On Mon, March 12, 2007 12:30 pm, Andreas Schwab wrote:
> "Roger Sayle" <roger@eyesopen.com> writes:
>> ! static inline __int64 __attribute__((__always_inline__))
>> ! _i64_popcnt (__int64 __A)
>> ! ...
>> !
>> ! extern inline __m64 __attribute__((__always_inline__))
>> ! _m64_mux1 (__m64 __A, const int __N)
>
> Some are static inline, some extern inline.

Thanks for noticing.  In my initial attempt, all functions were marked as
"static inline" following the precedent set by xmmintrin.h, emmintrin.h,
pmmintrin.h etc... in config/i386/.  Unfortunately,
I discovered that GCC attempts to expand the RTL for this style of
declaration, even in source files that don't mention any of the "static
inline" functions, but just #include the header.  This plays badly with
the constraint on the new __builtin_ia64_mux1 and __builtin_ia64_mux2
builtins that I add, that require their second arguments to be a
compile-time constant integer.

To avoid this problem I declare the two problematic builtins as "extern
inline" instead of "static inline", which according to the documentation
means that we never attempt to create out-of-line instances.

It might be that the RTL expansion of "static inline" functions that
aren't actually called is a bug in the cgraph code.  Alternatively, it
might make sense to declare all these builtins using "extern inline", not
just in the proposed changes to ia64intrin.h, but also in xmmintrin.h,
pmmintrin.h etc...  In the actual patch submission, I currently use
"extern inline" where I have to, and "static inline" elsewhere.

Roger
--



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]