-combine affects _mm_prefetch

[Freq]

Hi, All,

I am trying out "-combine" option on GCC to see if it will help to do
inter-object optimization. I have some mmx instructions using
instructions like "_mm_prefetch", and g++ complaints these symbols are
undefined. I did objdump on the object file compiled using "-combine",
and got these:
0000000000000000 *UND* 0000000000000000 _mm_prefetch
0000000000000000 *UND* 0000000000000000 _mm_sub_ps
0000000000000000 *UND* 0000000000000000 _mm_mul_ps
0000000000000000 *UND* 0000000000000000 _mm_add_ps

However, if I compile object files individually, these symbols doesn't
exists. How did this happen? What is the side effect by "-combine"?

Thanks.

Yifan Zhang
Speech Recognition Engineer

[Jan Seiffert]

Freq schrieb:

That the compiler will see the whole program at once, and optimize accordingly.

I think your problem is at another level.
These SIMD intrinsics come from a header file which is only avail. if the
compiler knows your CPU will support MMX (or SSE).
If your -march is not set right, the include will be empty, and those intrinsic
will look like a normal function call to the compiler.
With C code -Wimplicit would give you a warning in this case.

I guess, since you have to use you a different compile line for -combine, you
did not set -march in your options on that line.

There may be some funky implications with C++ & templates & instantiation &
virtual & foo, so the compiler, now "seeing" all the code, decided to generate
some code which didn't inline the functions, which is not possible, because
there are no not-inline versions of these functions.

At least the _mm_prefetch could be substituted for a __builtin_prefetch(), which
will work on any arch that supports prefetching.

> Thanks.
>
> Yifan Zhang
> Speech Recognition Engineer

Greetings
Jan

--
Staple guns: because duct tape can't make that 'kaCHUNK' noise.

[Freq]

Thank you for your reply.

On 7 Dec, 15:45, Jan Seiffert <nomail@invalid> wrote:
> Freq schrieb:
>
> > Hi, All,
>
> > I am trying out "-combine" option on GCC to see if it will help to do
> > inter-object optimization. I have some mmx instructions using
> > instructions like "_mm_prefetch", and g++ complaints these symbols are
> > undefined. I did objdump on the object file compiled using "-combine",
> > and got these:
> > 0000000000000000         *UND*  0000000000000000 _mm_prefetch
> > 0000000000000000         *UND*  0000000000000000 _mm_sub_ps
> > 0000000000000000         *UND*  0000000000000000 _mm_mul_ps
> > 0000000000000000         *UND*  0000000000000000 _mm_add_ps
>
> > However, if I compile object files individually, these symbols doesn't
> > exists. How did this happen? What is the side effect by "-combine"?
>
> That the compiler will see the whole program at once, and optimize accordingly.
>
> I think your problem is at another level.
> These SIMD intrinsics come from a header file which is only avail. if the
> compiler knows your CPU will support MMX (or SSE).
> If your -march is not set right, the include will be empty, and those intrinsic
> will look like a normal function call to the compiler.
> With C code -Wimplicit would give you a warning in this case.
>
> I guess, since you have to use you a different compile line for -combine, you
> did not set -march in your options on that line.

I didn't use -march, although I did use -msse4a for both compilation
line. If I don't use "-combine", _mm_* instructions are compiled to
native instructions, so I don't see those symbols in generated object
files.

>
> There may be some funky implications with C++ & templates & instantiation &
> virtual & foo, so the compiler, now "seeing" all the code, decided to generate
> some code which didn't inline the functions, which is not possible, because
> there are no not-inline versions of these functions.

I guess because g++ doesn't support "-combine", it will not optimize
the object generated by "-combine", and it will not replace _mm_* with
builtins.

>
> At least the _mm_prefetch could be substituted for a __builtin_prefetch(), which
> will work on any arch that supports prefetching.

The only reason that I prefer _mm_* to __builtin is that it compiles
under both GCC and VC++

[Jan Seiffert]

Freq schrieb:

Hmmmmmmm, that should have also solved this problem.

> If I don't use "-combine", _mm_* instructions are compiled to
> native instructions, so I don't see those symbols in generated object
> files.
>

Hmmm,

>>
>> There may be some funky implications with C++ & templates & instantiation &
>> virtual & foo, so the compiler, now "seeing" all the code, decided to generate
>> some code which didn't inline the functions, which is not possible, because
>> there are no not-inline versions of these functions.
>
> I guess because g++ doesn't support "-combine",

I don't know, the man page says the only supported language is C, still, this
means your other languages should be compiled "normaly"

> it will not optimize the object generated by "-combine",

gcc does not work on the objects, this will come with gcc 4.5 and lto.
In the -combine case gcc "concatenates" all compatible source files internally
and compiles them as one giant source (with a little special rules to prevent
name clashes and so on).

> and it will not replace _mm_* with builtins.
>

And at that compile stage all builtins should have been resolved, they should
not even reach the assembler or linker. Do you pass "-fno-builtin" by any chance?

>>
>> At least the _mm_prefetch could be substituted for a __builtin_prefetch(), which
>> will work on any arch that supports prefetching.
>
> The only reason that I prefer _mm_* to __builtin is that it compiles
> under both GCC and VC++
>

#ifdef __GNUC__
# define prefetch(x) __builtin_prefetch(x)
# define prefetchw(x) __builtin_prefetch(x, 1)
#else
# define prefetch(x) _mm_prefetch(x)
# define prefetchw(x) _mm_prefetch(x)
#endif

Greetings
Jan

--
Fun things to slip into your budged:
Traffic shaping on the loopback interface