about llvm2.7's inline assembly

Hello,

Whenever I compile a C program containing "FD_SET" function using llvm-gcc
2.7 (with -emit-llvm option), I got the following inline assembly in my
llvm byte code:

  %asmtmp = call %struct.__mbstate_t asm sideeffect "cld; rep; stosl",
"={cx},={di},{ax},0,1,~{dirflag},~{fpsr},~{flags},~{memory}"(i32 0, i32
32, i32* getelementptr inbounds (%struct.__sigset_t* @socks, i32 0, i32
0, i32 0)) nounwind ; <%struct.__mbstat %asmresult = extractvalue
%struct.__mbstate_t %asmtmp, 0 ; <i32> [#uses=1] store i32 %asmresult,
i32* %__d0
  %asmresult1 = extractvalue %struct.__mbstate_t %asmtmp, 1 ; <i32> [#uses=1]
  store i32 %asmresult1, i32* %__d1
  %0 = load i32* @sock, align 4

However, if I use llvm-gcc 2.6, this inline assembly function is not
generated in the byte code.

I was wondering if there is any way to "not generating" this inline
assembly function call in 2.7. Any comments will be appreciated.

Thank you!

Hi Sang Kil Cha,

Whenever I compile a C program containing "FD_SET" function using llvm-gcc
2.7 (with -emit-llvm option), I got the following inline assembly in my
llvm byte code:

this comes directly from your system headers (/usr/include/bits/select.h)
and as such doesn't really have anything to do with llvm-gcc:

#if defined __GNUC__ && __GNUC__ >= 2

# if __WORDSIZE == 64
# define __FD_ZERO_STOS "stosq"
# else
# define __FD_ZERO_STOS "stosl"
# endif

# define __FD_ZERO(fdsp) \
   do { \
     int __d0, __d1; \
     __asm__ __volatile__ ("cld; rep; " __FD_ZERO_STOS \
                           : "=c" (__d0), "=D" (__d1) \
                           : "a" (0), "0" (sizeof (fd_set) \
                                           / sizeof (__fd_mask)), \
                             "1" (&__FDS_BITS (fdsp)[0]) \
                           : "memory"); \
   } while (0)

#else /* ! GNU CC */

Maybe there's a good reason not to just use memset, but I don't know what it is.

Ciao,

Duncan.

this comes directly from your system headers (/usr/include/bits/select.h)
and as such doesn't really have anything to do with llvm-gcc:

iirc there were some fixincludes hacks for FD_ZERO thing. Maybe are
presented presented in one version and does not - in another, thus the
difference...

Hi Anton,

this comes directly from your system headers (/usr/include/bits/select.h)
and as such doesn't really have anything to do with llvm-gcc:

iirc there were some fixincludes hacks for FD_ZERO thing. Maybe are
presented presented in one version and does not - in another, thus the
difference...

IIRC the fixincludes hack was done so that the asm would not crash the compiler,
the problem being that "int" (32 bits) is being passed to the asm even on 64
bit machines; it should be "long". But the asm itself is coming from glibc.

Ciao,

Duncan.

IIRC the fixincludes hack was done so that the asm would not crash the
compiler,
the problem being that "int" (32 bits) is being passed to the asm even on 64
bit machines; it should be "long". But the asm itself is coming from glibc.

Yes, however from the original report it's unclear how the versions of
llvm-gcc were built.
It's possible e.g. that 2.6 one was some pre-packaged one bringing the
"fixed" header from other version of glibc.